fix(ci): tag releases automatically and keep previews off the production schema - #82
Conversation
github-actions
Bot
changed the title
carhartlewis
changed the title
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
1 issue found across 4 files (changes from recent commits).
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name=".github/workflows/release.yml">
<violation number="1" location=".github/workflows/release.yml:42">
P2: The diagnostic never runs for the jam it is meant to explain: release-please aborts first, and GitHub Actions skips later steps after a failure by default. Adding an explicit `if: ${{ !cancelled() }}` condition would let this query and summary run after release-please fails while still avoiding canceled runs.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Fix all with cubic | Re-trigger cubic
| echo "No tag this run — either the release pull request is still open, or nothing releasable landed." >> "$GITHUB_STEP_SUMMARY" | ||
| fi | ||
|
|
||
| - name: Fail on a merged release pull request that was never tagged |
There was a problem hiding this comment.
P2: The diagnostic never runs for the jam it is meant to explain: release-please aborts first, and GitHub Actions skips later steps after a failure by default. Adding an explicit if: ${{ !cancelled() }} condition would let this query and summary run after release-please fails while still avoiding canceled runs.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/release.yml, line 42:
<comment>The diagnostic never runs for the jam it is meant to explain: release-please aborts first, and GitHub Actions skips later steps after a failure by default. Adding an explicit `if: ${{ !cancelled() }}` condition would let this query and summary run after release-please fails while still avoiding canceled runs.</comment>
<file context>
@@ -38,3 +38,23 @@ jobs:
echo "No tag this run — either the release pull request is still open, or nothing releasable landed." >> "$GITHUB_STEP_SUMMARY"
fi
+
+ - name: Fail on a merged release pull request that was never tagged
+ env:
+ GH_TOKEN: ${{ secrets.AUTOMATION_TOKEN || secrets.GITHUB_TOKEN }}
</file context>
| - name: Fail on a merged release pull request that was never tagged | |
| - name: Fail on a merged release pull request that was never tagged | |
| if: ${{ !cancelled() }} |
There was a problem hiding this comment.
1 issue found and verified against the latest diff
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name=".github/release-please-config.json">
<violation number="1" location=".github/release-please-config.json:28">
P2: This edit removes the explicit `pull-request-title-pattern` and enables `separate-pull-requests: true`. With a single root package the default title pattern kicks in, so the release pull request title changes from `chore(release): 1.4.0` to release-please's default `chore(main): release 1.4.0` (default is `chore${scope}: release${component} ${version}`, and `scope` is the target branch name). Two consequences: 1) it silently diverges from what CONTRIBUTING.md documents as the release PR title (`chore(release): 0.2.0`); 2) release-please matches an already-open release PR by the title pattern and parses the version back out of it, so if a release PR is pending when this ships, the next run won't recognize it and can open a duplicate — the exact "untagged merged release PRs outstanding" jam this repo just recovered from. I'd keep an explicit, stable `pull-request-title-pattern` (e.g. `chore(release): ${version}`) rather than relying on the default, and sync CONTRIBUTING.md with whatever title is chosen.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Fix all with cubic | Re-trigger cubic
| "bootstrap-sha": "64f154b086cbad6cac232357dc21c954543ef217", | ||
| "separate-pull-requests": false, | ||
| "pull-request-title-pattern": "chore(release): ${version}", | ||
| "separate-pull-requests": true, |
There was a problem hiding this comment.
P2: This edit removes the explicit pull-request-title-pattern and enables separate-pull-requests: true. With a single root package the default title pattern kicks in, so the release pull request title changes from chore(release): 1.4.0 to release-please's default chore(main): release 1.4.0 (default is chore${scope}: release${component} ${version}, and scope is the target branch name). Two consequences: 1) it silently diverges from what CONTRIBUTING.md documents as the release PR title (chore(release): 0.2.0); 2) release-please matches an already-open release PR by the title pattern and parses the version back out of it, so if a release PR is pending when this ships, the next run won't recognize it and can open a duplicate — the exact "untagged merged release PRs outstanding" jam this repo just recovered from. I'd keep an explicit, stable pull-request-title-pattern (e.g. chore(release): ${version}) rather than relying on the default, and sync CONTRIBUTING.md with whatever title is chosen.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At .github/release-please-config.json, line 28:
<comment>This edit removes the explicit `pull-request-title-pattern` and enables `separate-pull-requests: true`. With a single root package the default title pattern kicks in, so the release pull request title changes from `chore(release): 1.4.0` to release-please's default `chore(main): release 1.4.0` (default is `chore${scope}: release${component} ${version}`, and `scope` is the target branch name). Two consequences: 1) it silently diverges from what CONTRIBUTING.md documents as the release PR title (`chore(release): 0.2.0`); 2) release-please matches an already-open release PR by the title pattern and parses the version back out of it, so if a release PR is pending when this ships, the next run won't recognize it and can open a duplicate — the exact "untagged merged release PRs outstanding" jam this repo just recovered from. I'd keep an explicit, stable `pull-request-title-pattern` (e.g. `chore(release): ${version}`) rather than relying on the default, and sync CONTRIBUTING.md with whatever title is chosen.</comment>
<file context>
@@ -25,7 +25,6 @@
"bootstrap-sha": "64f154b086cbad6cac232357dc21c954543ef217",
- "separate-pull-requests": false,
- "pull-request-title-pattern": "chore(release): ${version}",
+ "separate-pull-requests": true,
"pull-request-header": "The changelog below is what will be published as the release notes. Edit the commit subjects, not this PR body — the body is regenerated on every push to main. Merge this before the promotion pull request, so the tag lands on the commit `release` receives."
}
</file context>
1 participant
v1.0.0throughv1.3.0were all tagged by hand. Automatic tagging has never worked here, and#81 shipped the agent builder to
releaseuntagged and unbumped because of it.Why. With
separate-pull-requests: falseand one package, release-please's Merge pluginrenames the release branch from
release-please--branches--main--components--crmtorelease-please--branches--main. On merge,strategies/base.tsreads the component back out ofthat branch name and compares it to the package name —
undefinednever equalscrm, so it warnsPR component: undefined does not match configured component: crmand tags nothing. The PR keepsautorelease: pending, and every later run aborts withThere are untagged, merged release PRs outstanding. That is wheremainhas been since 15:49 on 7 Aug.pull-request-title-patternwas a second, independent break:chore(release): ${version}has no${scope}or${component}(release-please warns six times a run) and its(release)compiles toa regex capture group, so it matched nothing and the fallback title parse failed too.
separate-pull-requests: true— one package, so still exactly one PR, now on a branch the taggingstep can read. Verified with
release-please release-pr --dry-run: branchrelease-please--branches--…--components--crm,updating from 1.3.0 to 1.4.0.chore(main): release 1.4.0.autorelease: pending. Silence wasthe whole problem: three days of merges reported success while releasing nothing.
Migrations.
build-func.mjsranprisma migrate deployon every crm-api build, andDATABASE_URLis one value across production, preview and development — so preview builds migratedthe production database. On 7 Aug the live schema ran six migrations ahead of the live code all day,
and the production deploy of #81 found nothing to apply because a preview had already applied it.
Gated on
VERCEL_ENV === "production". The tradeoff is documented: until previews get their owndatabase, a preview of a schema-changing branch runs against a database without its tables.
v1.3.0 was tagged and #78 relabelled by hand to clear the current jam; v1.2.0 was tagged too, so the
changelog's compare links resolve.