|
3 | 3 | All notable changes are recorded here and summarized again in the matching |
4 | 4 | GitHub release notes for each tag. |
5 | 5 |
|
| 6 | +## v0.2.0 |
| 7 | + |
| 8 | +**This release makes the product installable by someone who is not us.** Every |
| 9 | +change below comes from one root cause: it was built by the account that owns |
| 10 | +the GitHub App, so the vendor case and the adopter case had never been |
| 11 | +separated. Four of the defects were only reachable by an adopter, which is why |
| 12 | +none of them had been seen. |
| 13 | + |
| 14 | +**Breaking.** The command prefix and two configuration names change. There are |
| 15 | +no known installations other than this repository, so no migration path is |
| 16 | +provided; set the new names and regenerate the caller workflow. |
| 17 | + |
| 18 | +- **You create your own GitHub App, and `init` now explains how.** The setup |
| 19 | + instructions told every adopter to create an App named `simplycubed-code`. |
| 20 | + App names are globally unique and we hold that one, so the step was only |
| 21 | + performable by the account that already owns it; everyone else got "Name has |
| 22 | + already been taken". Neither `init` nor the docs said why the App must be |
| 23 | + theirs: the private key is what mints tokens against their repository, so a |
| 24 | + shared key would let its holder act on every other installation. That single |
| 25 | + missing sentence is what made "create a GitHub App" read as busywork we could |
| 26 | + have done for them. `init` now prints the creation URL, resolved to the |
| 27 | + organisation form when the repository belongs to one, the three permissions |
| 28 | + with their access levels, webhook off and why, install visibility and why it |
| 29 | + is the step most often missed, and where the `Iv23` Client ID and the |
| 30 | + download-once private key come from. |
| 31 | +- **Comment commands are `/simplycubed`, not `@simplycubed-code`.** An |
| 32 | + @-mention of our App cannot be right in anyone else's repository: their bot |
| 33 | + carries a different login, so the trigger matched nothing, and because our App |
| 34 | + is public the handle rendered there as a mention of an account they had never |
| 35 | + installed. The parser held the same literal, so templating the workflow |
| 36 | + trigger alone would not have helped. A prefix that is not a handle needs no |
| 37 | + templating and keeps one static caller workflow. |
| 38 | +- **Workflow-push restriction is decided by identity, not by our App's name.** |
| 39 | + The check compared the authenticated login against a hardcoded |
| 40 | + `simplycubed-code[bot]`, so for every adopter it was false and the pre-flight |
| 41 | + never ran. They learned about the refusal at push time instead, after a full |
| 42 | + loop and its model spend. Any `[bot]` login is now restricted; an empty login |
| 43 | + stays unrestricted, because that is a human running locally and a human can |
| 44 | + push workflow files. |
| 45 | +- **Escalations name the files that caused them.** "the change touches |
| 46 | + `.github/workflows/`" left a reader with nothing but the agent's own account |
| 47 | + of what it had edited, which is not evidence. Working out whether one real |
| 48 | + escalation was correct cost two investigation rounds and produced a wrong |
| 49 | + diagnosis. The message now lists the paths git actually reported. |
| 50 | +- **The gate no longer stamps VCS metadata into binaries it throws away.** |
| 51 | + `go build` failed in the loop's worktree with `error obtaining VCS status: |
| 52 | + exit status 128` before any repository code compiled, so every agent run |
| 53 | + reported a red gate for a reason unrelated to the change under test. A gate |
| 54 | + that cannot run where the loop runs is not a gate. |
| 55 | +- **One naming scheme for the four values an adopter sets.** Two carried the |
| 56 | + `SIMPLYCUBED_` prefix and two did not, so on an organisation settings page the |
| 57 | + four did not read as one tool's configuration and nobody auditing later could |
| 58 | + tell what `AZURE_OPENAI_API_KEY` belonged to. The unprefixed pair was also the |
| 59 | + conventional name for that credential, so an organisation already using Azure |
| 60 | + OpenAI either hit a conflict or silently shared one key between this runtime |
| 61 | + and something unrelated. |
| 62 | + |
| 63 | + | Section | Name | |
| 64 | + | --- | --- | |
| 65 | + | Variables | `SIMPLYCUBED_GH_APP_CLIENT_ID` | |
| 66 | + | Secrets | `SIMPLYCUBED_GH_APP_PRIVATE_KEY` | |
| 67 | + | Variables | `SIMPLYCUBED_AZURE_OPENAI_ENDPOINT` (was `AZURE_OPENAI_ENDPOINT`) | |
| 68 | + | Secrets | `SIMPLYCUBED_AZURE_OPENAI_API_KEY` (was `AZURE_OPENAI_API_KEY`) | |
| 69 | + |
| 70 | + `SIMPLYCUBED_SELF_LOGIN` becomes `SIMPLYCUBED_GH_APP_LOGIN`; it parsed as |
| 71 | + "SimplyCubed's login" when it means the bot identity the run holds. |
| 72 | +- **`preflight` checks those four and names the section a missing one belongs |
| 73 | + in.** Nothing checked them until a real run failed, and the one thing that did |
| 74 | + was deleted at the end of install: the self-test names the section, then |
| 75 | + `init` tells the adopter to remove it. Variables and Secrets are different |
| 76 | + tabs, and a value filed under the wrong one reads back as empty rather than |
| 77 | + failing, which happened during a real install and was found by reading the |
| 78 | + caller workflow. A configuration miss now exits `3`, so a caller can tell "go |
| 79 | + and set this" from a bug without matching on message text. |
| 80 | +- **Removed the `github-app-id` workflow input.** It survived as a fallback for |
| 81 | + callers that do not exist, and it invited the wrong credential: the name says |
| 82 | + App *ID*, the numeric one, while the token action needs the `Iv23` client ID. |
| 83 | + |
6 | 84 | ## v0.1.9 |
7 | 85 |
|
8 | 86 | - **The GitHub Actions runtime does the work now.** Until this release the |
|
0 commit comments