Conversation
…erit (#76) Two small workflow follow-ups that have been outstanding through PR #70 and PR #74 reviews. ## 1. `get-version-task.yml` — carve out the `dotnet/nbgv@master` exception in comments `dotnet/nbgv` is the only third-party action in this repo that's not SHA-pinned. Copilot has flagged this twice now ([PR #70](#70) and again in passing). Adding an inline comment that explicitly documents it as the AGENTS.md exception so future reviewers / agents don't keep flagging it. Reasoning recorded in the comment: - Upstream tag stream is dormant — latest tag `v0.5.1` (`3cf2d96c…`) lags `master` (`b944774b…` as of today). Real fixes accumulate on `master` between tag bumps. - Dependabot's GitHub Actions ecosystem tracks tagged releases. If we pin to a post-`v0.5.1` `master` SHA, Dependabot will either silently stall (no new tags to bump to) or attempt a **downgrade** PR to `v0.5.1`. Neither beats just floating on `master`. - Upstream owner is Microsoft (`dotnet/`), so the tag-/branch-retargeting risk the rule guards against is materially lower than for a random-author action. ## 2. `build-nugetlibrary-task.yml` — drop redundant `secrets: inherit` `get-version-task.yml` declares no required secrets in its `on: workflow_call` block, so `secrets: inherit` on the `get-version` job call was passing the caller's secret context to a job that consumes none. Same fix [PR #74](#74) applied to `build-pypilibrary-task.yml`; flagged by Copilot there but declined here for opportunistic-pin scope. This PR closes the gap. ## Test plan - [ ] CI passes on this PR. - [ ] No behavior change on either workflow (NBGV invocation unchanged, version outputs identical, no secrets actually consumed by `get-version`). --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates reusable GitHub Actions workflows to (1) document an intentional exception to the repository’s third-party action SHA-pinning convention and (2) reduce secret exposure by removing an unnecessary secrets: inherit from a reusable workflow call.
Changes:
- Document why
dotnet/nbgv@masteris intentionally not SHA-pinned inget-version-task.ymlto prevent accidental “fixes” in future reviews. - Remove redundant
secrets: inheritfrom theget-versionreusable workflow call inbuild-nugetlibrary-task.yml.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| .github/workflows/get-version-task.yml | Adds an inline comment justifying the intentional dotnet/nbgv@master exception to the third-party action pinning rule. |
| .github/workflows/build-nugetlibrary-task.yml | Removes secrets: inherit from the get-version job call to avoid widening secret context unnecessarily. |
…ull docs (#78) Codifies the branching model AGENTS.md actually implies and aligns the bots/docs to match. Closes the gap that made me push two unnecessary admin-bypass back-merges (`ffb9e64` and `5ce95cf`) — those violated the develop squash-only ruleset and shouldn't have happened. ## What changes ### Workflow + config | File | Change | |---|---| | `.github/dependabot.yml` | Every ecosystem (`nuget`, `github-actions`, `uv`) now has **two entries** — one with `target-branch: "main"`, one with `target-branch: "develop"`. Dependabot opens parallel PRs against each branch independently. | | `.github/workflows/run-codegen-pull-request-task.yml` | Codegen runs as a **matrix** over `main` and `develop`. Branches `codegen-main` and `codegen-develop`; each opens a PR against its own base. `fail-fast: false` so a per-branch failure doesn't block the other. | | `.github/workflows/merge-bot-pull-request.yml` `merge-codegen` | Accepts both head/base pairings (`codegen-main → main`, `codegen-develop → develop`) with strict pairing to prevent cross-targeting. Merge step uses the same `case` statement as `merge-dependabot` to dispatch `--squash` (develop) vs `--merge` (main) per base. | ### Documentation - **AGENTS.md "Branching Model"** — new bullets codifying forward-only develop (no main → develop back-merges; develop squash-only ruleset blocks them) and the dual-target bot pattern with rationale. - **README.md "Template - Branching Workflow"** — rewritten to mirror AGENTS.md. Drops the stale "Squash and merge from develop to main" and "bots merge into main directly" lines. - **README.md "Template - Release Distribution Model: Push vs. Pull"** (new section) — documents the default push-on-merge release model (every commit on main → release) and walks through the manual-release alternative for HACS / distro-vendored projects, referencing [homeassistant-purpleair](https://github.com/ptr727/homeassistant-purpleair) as the working example. - **README.md "Template - GitHub Setup"** — codegen auto-merge condition updated for the new head/base pairing + actor check + dual-target pointer. Rulesets section split into Develop (squash-only) and Main (merge-only) with shared settings called out. ## Why dual-target, not develop-only Considered develop-only-with-flow-through (codegen and Dependabot target develop only; main picks up changes through develop → main releases). Two problems with that model: 1. **Push-distribution channels consume `main` directly** — HACS, distros that vendor from main, Linux package managers. If main only got dep bumps via the next develop → main release and the release cadence is tied to feature completion, main runs stale code for weeks. 2. **Codegen content can be production-critical.** This template's codegen is trivial demo content (quote-of-the-day, date stamps), but derived projects can use codegen for live API-derived data (language lists, build catalogs, license databases). Stale codegen on main isn't merely cosmetic. Dual-target keeps both branches current on their own cadence, no back-merges, forward-only invariant preserved. ## Test plan - [ ] CI passes on this PR. - [ ] After merge to develop, the next Dependabot scheduled run opens **two** PRs per ecosystem (one against main, one against develop). - [ ] Next codegen run opens **two** PRs (one against main, one against develop). - [ ] Each PR auto-merges via the merge-bot using the correct method (`--squash` for develop, `--merge` for main). - [ ] No more back-merges land on develop. --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ptr727
changed the title
ptr727
enabled auto-merge
May 11, 2026 23:45
ptr727
disabled auto-merge
May 11, 2026 23:49
This was referenced May 12, 2026
Merged
ptr727
added a commit
that referenced
this pull request
May 12, 2026
…forward-only) (#81) Resolves the root cause behind why [PR #80](#80) (the develop → main release) is blocked by "the head branch is not up to date with the base branch". The forward-only develop model PR #78 codified is fundamentally incompatible with the ruleset's `Require branches to be up to date before merging` rule, and the README's documented "shared settings" block hid the contradiction. ## What's actually happening The "up to date" check is **graph-based**: it asks "is main's tip commit reachable from develop?", not "does develop have main's content?". After any develop → main release, main has a new merge commit (e.g. `fb10a16` from PR #77) whose first-parent walk isn't in develop's history. Develop is strictly *ahead* in content but "behind" in graph terms. Historical back-merge commits (`ffb9e64`, `5ce95cf`) had been **quietly compensating** for this — each one created a develop commit whose second parent was main's release-merge commit, making main's tip reachable from develop. PR #78 codified forward-only and forbade back-merges, but the README rulesets section still listed `Require branches to be up to date` as a shared setting. The contradiction was invisible until the first release without a preceding back-merge tried to land — which is PR #80. ## What this PR changes - **`README.md`** "Rules / Rulesets": move `Require branches to be up to date before merging` out of "Shared settings" and into the Develop-only ruleset entry (where it's standard hygiene for feature → develop merges). Add explicit "intentionally OFF" callout in the Main ruleset entry with the full rationale. - **`AGENTS.md`** "Branching Model": new bullet codifying *why* the main ruleset omits this rule, with a pointer to README for the configured state. ## What you'll need to do in the GitHub UI Untick `Require branches to be up to date before merging` in **Settings → Rulesets → Main**. That's a config change, not a code change, and rulesets are security-sensitive so it stays your direct action. After: - PR #80 will merge cleanly via `gh pr merge --merge` (no admin bypass needed). - Future develop → main releases land without admin bypass. ## Test plan - [ ] CI passes on this PR. - [ ] After merge to develop, PR #80's head auto-advances to include this docs update. - [ ] After you untick the rule on Settings → Rulesets → Main, PR #80 merges cleanly without `--admin`. - [ ] Future develop → main releases also land without admin bypass (the safeguard PR #79's content joins this release on main once PR #80 lands). --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Release merge: brings two squashed PRs and one unnecessary back-merge commit from
developintomain.Squashed PRs included
Document dotnet/nbgv@master exception and drop redundant secrets: inherit #76 — Document
dotnet/nbgv@masterexception and drop redundantsecrets: inherit..github/workflows/get-version-task.yml: inline comment carves outdotnet/nbgv@masteras the deliberate deviation from the AGENTS.md SHA-pinning rule (upstream tag stream is dormant, Dependabot would stall or attempt a downgrade if we pinned, upstream owner is Microsoft so retargeting risk is low)..github/workflows/build-nugetlibrary-task.yml: droppedsecrets: inheritfrom theget-versionjob call (same fix PR Publish PyPI on develop as PEP 440 dev releases (prerelease channel) #74 applied tobuild-pypilibrary-task.yml).Forward-only develop with dual-target Dependabot + codegen; push-vs-pull docs #78 — Forward-only develop with dual-target Dependabot + codegen. The substantive change in this release:
main → developback-merges; develop squash-only ruleset blocks them) and the dual-target bot model with rationale..github/dependabot.ymlduplicates every ecosystem entry per branch (six entries total) so Dependabot opens parallel PRs against bothmainanddevelopindependently. Both branches stay current on dep versions without back-merges..github/workflows/run-codegen-pull-request-task.ymlruns as a matrix overmainanddevelop. Branch namescodegen-mainandcodegen-develop; each opens a PR against its own base..github/workflows/merge-bot-pull-request.ymlmerge-codegenjob uses strict head/base pairing and dispatches--squash(develop) vs--merge(main) per base, samecasestatement pattern asmerge-dependabot.Require linear history) and Main (merge-commit-only) rulesets with shared settings extracted. Repo-level Pull Requests block now correctly shows bothAllow merge commitsandAllow squash mergingenabled (the prior wording suggested merge would be disabled, which contradicted the actual main ruleset).Unnecessary back-merge
5ce95cf(acknowledged misstep)I opened this release with a
Merge remote-tracking branch 'origin/main' into developcommit assuming the back-merge pattern was the standard cycle close. It wasn't. That model conflicts with AGENTS.md's squash-only develop rule (the push only succeeded via admin bypass). PR #78's AGENTS.md update now explicitly forbids future back-merges and routes both bots to update both branches independently — closing the gap that made this pattern feel necessary.The back-merge commit is left in place: reverting requires a destructive force-push to develop. Behavioral effect is a one-time gitHeight bump, which fixes the
--prechannel ordering (develop's next dev publish is now unambiguously higher than main's last release).Operator action items (already completed)
CODEGEN_APP_ID/CODEGEN_APP_PRIVATE_KEYin both Actions and Dependabot secret stores. ✓WORKFLOW_PATsecret + PAT revoked. ✓pypiGitHub environment Deployment branch rule allowsmainanddevelop. ✓Open follow-up (tracked separately, not in this release)
PR #78 documented a limitation in the actor-check guardrail on
merge-codegen/merge-dependabot: it stops the merge-bot from re-invokinggh pr merge --autoon a maintainer-triggeredsynchronize, but does not disable auto-merge that's already enabled. Once auto-merge is on a bot PR, maintainer commits will land. The honest workaround is documented (gh pr merge --disable-auto <PR>before pushing). The real safeguard — asynchronize-triggered job that disables auto-merge automatically when the actor isn't the bot — is a follow-up PR I'll open after this release lands.Notes
Test plan
publish-release.ymlon main publishes1.0.<N>.<B>as the next stable release.pip install ptr727-projecttemplate-libraryresolves to the new stable;pip install --pre ptr727-projecttemplate-libraryresolves to the latest develop dev (assuming develop's gitHeight exceeds main's, which the back-merge ensures).codegen-mainagainst main,codegen-developagainst develop).--squashfor develop,--mergefor main).