|
| 1 | +# Functions — Hugr Agent Instructions |
| 2 | + |
| 3 | +Repository: https://github.com/knative/func |
| 4 | + |
| 5 | +This file is kept in the hugr repo and symlinked into func src workspaces for |
| 6 | +agents. |
| 7 | + |
| 8 | +## Testing |
| 9 | + |
| 10 | +### Quick validation: `make check` |
| 11 | + |
| 12 | +Run `make check` before signaling completion. It runs linting, vet, and |
| 13 | +template checks — fast enough to run on every change. |
| 14 | + |
| 15 | +### Unit tests: `make test` |
| 16 | + |
| 17 | +Run `make test` for unit-level validation. Sufficient for most changes — |
| 18 | +bug fixes, refactors, new functions with test coverage. |
| 19 | + |
| 20 | +### Full E2E suite |
| 21 | + |
| 22 | +The full E2E test suite (`make test-e2e`) runs against a live Kind cluster |
| 23 | +with a local registry, Knative Serving/Eventing, Tekton, and MetalLB. It |
| 24 | +deploys real functions, invokes them, and validates the full lifecycle. |
| 25 | + |
| 26 | +**When to run locally:** |
| 27 | +- Debugging CI failures that don't reproduce with unit tests alone |
| 28 | +- Validating changes to cluster infrastructure (`pkg/cluster/`) |
| 29 | +- Changes to the deploy/build/push pipeline |
| 30 | +- Before pushing complex multi-file changes that touch the runtime path |
| 31 | + |
| 32 | +**When it's unnecessary:** |
| 33 | +- Small, well-tested changes where `make test` passes |
| 34 | +- Documentation, template, or tooling changes |
| 35 | +- The full suite runs in remote CI on every PR — local runs are for |
| 36 | + replicability and confidence, not gating |
| 37 | + |
| 38 | +**Prerequisites:** |
| 39 | +``` |
| 40 | +export FUNC_ENABLE_CLUSTER=1 |
| 41 | +export FUNC_E2E_KUBECONFIG=~/.config/func/clusters/func.local/kubeconfig.yaml |
| 42 | +``` |
| 43 | + |
| 44 | +Create the cluster first with `func cluster create --tekton` (requires the binary |
| 45 | +built and `FUNC_ENABLE_CLUSTER=1`). The E2E suite takes ~30 minutes. |
| 46 | + |
| 47 | +## Landing flow |
| 48 | + |
| 49 | +Work in your jj workspace (`$SHARD_ROOT/src/`). When ready to land: |
| 50 | + |
| 51 | +1. Clean commits — squash fixups, reword for clarity |
| 52 | +2. Run `make check` (always) and `make test` (minimum) |
| 53 | +3. DM your requester for review, including test results |
| 54 | +4. After approval, push and open a PR: |
| 55 | + ``` |
| 56 | + jj git push -c @- # or whichever commit; creates a remote tracking branch |
| 57 | + ``` |
| 58 | + Then open a PR against upstream with a clear explanation of the change. |
| 59 | +5. PR must pass CI (unit tests, integration tests, linting) |
| 60 | + |
| 61 | +## Conventions |
| 62 | + |
| 63 | +- Follow upstream Go conventions (gofmt, govet, golint) |
| 64 | +- Tests are required for new functionality |
| 65 | +- Commit messages follow Conventional Commits format |
| 66 | +- Keep PRs focused — one logical change per PR |
| 67 | + |
| 68 | +## Managing multiple changes |
| 69 | + |
| 70 | +### Independent changes (simultaneous PRs) |
| 71 | + |
| 72 | +Base each change on upstream's `main` so it can be pushed and PR'd |
| 73 | +independently, without waiting on other pending work. This avoids stalling |
| 74 | +when one PR is slow to merge. |
| 75 | + |
| 76 | +``` |
| 77 | +jj new main # start Feature A from main |
| 78 | +# ... work ... |
| 79 | +jj git push -c @- # push Feature A, open PR |
| 80 | +
|
| 81 | +jj new main # start Bugfix A from main (not from Feature A) |
| 82 | +# ... work ... |
| 83 | +jj git push -c @- # push Bugfix A, open separate PR |
| 84 | +
|
| 85 | +jj new main # start Feature C from main |
| 86 | +# ... work ... |
| 87 | +``` |
| 88 | + |
| 89 | +Each change gets its own bookmark (auto-created by `jj git push`) and its |
| 90 | +own PR. They can land in any order. |
| 91 | + |
| 92 | +### Dependent changes (sequential PRs) |
| 93 | + |
| 94 | +When a change depends on another that already has an open PR, make it a |
| 95 | +descendant of the prerequisite change. Do **not** push or open a PR until |
| 96 | +the prerequisite has been merged into `main`. |
| 97 | + |
| 98 | +``` |
| 99 | +jj new main # Feature A: independent, can PR now |
| 100 | +# ... work ... |
| 101 | +jj git push -c @- # push Feature A |
| 102 | +
|
| 103 | +jj new <feature-a> # Feature B: depends on A, descends from it |
| 104 | +# ... work ... |
| 105 | +# wait for Feature A to land before pushing Feature B |
| 106 | +``` |
| 107 | + |
| 108 | +A change may depend on multiple prerequisites — create it with multiple |
| 109 | +parents to reflect that. It should not be pushed until all prerequisites |
| 110 | +appear in `main`. |
| 111 | + |
| 112 | +### Syncing after upstream merges |
| 113 | + |
| 114 | +When a PR has been merged upstream (or when a rebase is required for it to |
| 115 | +land): |
| 116 | + |
| 117 | +``` |
| 118 | +jj git fetch --remote upstream |
| 119 | +jj rebase -d upstream/main # rebase working changes onto updated main |
| 120 | +``` |
| 121 | + |
| 122 | +Upstream uses merge commits, so your merged changes will appear as a new |
| 123 | +commit ID on `main`. Your local copies will show as "empty" (their diff is |
| 124 | +now included in the merge commit). At that point, those empty changes can |
| 125 | +be safely abandoned with `jj abandon`. |
| 126 | + |
| 127 | +**Workspace hygiene:** |
| 128 | +- Only perform these operations in your own workspace |
| 129 | +- Only abandon changes that you authored — never touch other agents' work |
| 130 | +- Track change IDs and their push bookmarks on the associated issue for |
| 131 | + quick lookup |
| 132 | + |
| 133 | +## Branch strategy |
| 134 | + |
| 135 | +- Branches are auto-created by `jj git push` — no manual branch management |
| 136 | +- PRs target `main` unless otherwise specified |
0 commit comments