ENG-1767 Setup Linear release for Obsidian - #1253
Conversation
Add a manual stable_obsidian_release.yaml workflow that publishes a stable Obsidian version and syncs/completes the matching Linear release. publish.ts now writes the resolved version back into local package.json/manifest.json (previously only the mirror-repo copy was updated, so the local version field was permanently stale) so the workflow's guard step has an accurate baseline to compare against. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
This pull request has been ignored for the connected project Preview Branches by Supabase. |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
A new stable 1.5.2 release was just cut manually, so update the one-time baseline correction to match instead of the now-stale 1.5.1. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
![graphite-app[bot]](https://avatars.githubusercontent.com/in/158384?s=60&v=4){kind=small}
packages/database/src/dbDotEnv.mjs unconditionally overrides SUPABASE_USE_DB to "implicit" (or "none") whenever running under GitHub Actions with GITHUB_TEST != "test", regardless of what the variable is set to. So SUPABASE_USE_DB=production was dead in CI. SUPABASE_URL/SUPABASE_PUBLISHABLE_KEY alone are enough to trigger the implicit-mode fallback, same as roam-release.yaml/roam-main.yaml. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Both steps contradicted the documented release process: README step 1 tells maintainers to bump package.json to the target version before dispatching, but the guard rejected exactly that state as "already released" (flagged independently by Devin and Graphite review). roam-release.yaml has no equivalent safeguard at all — it trusts package.json outright. Do the same here: devs are expected to pass a sane version, so drop both checks rather than patch the guard to special-case the pre-bumped state. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ea8818f83c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - name: Complete Linear release | ||
| uses: linear/linear-release-action@v0 |
There was a problem hiding this comment.
If either Linear action fails after the GitHub release has been published—for example, during a transient Linear API failure—rerunning this workflow starts with publish.ts again. Its createGithubRelease function unconditionally creates a release for the same tag, so the duplicate release request fails before the workflow can retry the sync or completion step. Make publishing idempotent or separate the post-publish Linear operations so a partially successful release can be resumed.
Useful? React with 👍 / 👎.
| - name: Sync Linear release | ||
| uses: linear/linear-release-action@v0 | ||
| with: | ||
| access_key: ${{ secrets.LINEAR_RELEASES_ACCESS_KEY }} |
There was a problem hiding this comment.
This key is already used for the Roam pipeline. I don't think we can reuse this same access key.
| @@ -0,0 +1,68 @@ | |||
| name: Stable Obsidian Release | |||
There was a problem hiding this comment.
let's match the naming style of all the other files in this folder
| - name: Publish stable release | ||
| run: cd apps/obsidian && npx tsx scripts/publish.ts --version ${{ inputs.version }} | ||
|
|
||
| - name: Commit version bump |
There was a problem hiding this comment.
Is the intent that the PR changes the manifsest.json and package.json (as the README says), or that the GitHub action will do this?
There was a problem hiding this comment.
the Github action will do this. Because publish.ts only changes manifest.json and package.json when the version is set to stable (see isExternalRelease)
There was a problem hiding this comment.
So should we change the README to reflect this?
| run: pnpm install --frozen-lockfile | ||
|
|
||
| - name: Publish stable release | ||
| run: cd apps/obsidian && npx tsx scripts/publish.ts --version ${{ inputs.version }} |
There was a problem hiding this comment.
${{ inputs.version }} is inserted into the generated Bash script before it runs. A value like 1.6.0; <command> ends the publisher command and executes the appended command with repository write access and the job’s mirror token and Supabase values.
publish.ts can’t prevent this because Bash parses the separator before Node receives the arguments. Its version regex is also only anchored at the start, so it accepts trailing content when that content reaches Node.
Pass the input through an environment variable, validate it against a fully anchored stable-version pattern, and use a quoted variable:
env:
VERSION: ${{ inputs.version }}
run: npx tsx scripts/publish.ts --version "$VERSION"Use the same validated variable in the commit message. This keeps the version as data instead of inserting it into the shell script.
2 participants
Summary
stable_obsidian_release.yamlworkflow (workflow_dispatch) that publishes an official stable Obsidian version viapublish.ts, then syncs and completes the matching Linear releasepublish.tsso it writes the resolved version back into the localapps/obsidian/package.json/manifest.json(previously only the mirror-repo copy was updated, so the local version field was permanently stale at0.1.0)package.json/manifest.jsonfrom stale0.1.0to1.5.1, matching the actual latest stable release in thediscourse-graph-obsidianmirror repoapps/obsidian/README.mdSupersedes closed PR #1074, which used an older 3-workflow design without the merge-time tracking piece. That piece is now split out to ENG-1994 (#1254, stacked on this PR).
Test plan
To test this workflow, I need to merge them first. Rationale:
GitHub only allows manually triggering a workflow_dispatch workflow once its file exists on the default branch (main) — per their docs: "This event will only trigger a workflow run if the workflow file exists on the default branch."
js-yamlparse check on the new workflow YAMLtsc --noEmitandeslintclean onpublish.tsstable_obsidian_release.yamlwith a real version matching an existing Linear release and confirm the GitHub release, mirror repo push, and Linear sync/complete all succeed