ENG-1994 Automatically add merged Obsidian issues to in-progress Linear release - #1254
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
This pull request has been ignored for the connected project Preview Branches by Supabase. |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
![graphite-app[bot]](https://avatars.githubusercontent.com/in/158384?s=60&v=4){kind=small}
78cf47b to
13ff66b
Compare
|
@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: 6d9e9f70ba
ℹ️ 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".
| git config user.email "github-actions[bot]@users.noreply.github.com" | ||
| git add apps/obsidian/package.json apps/obsidian/manifest.json | ||
| git commit -m "chore: bump obsidian version to ${{ steps.version.outputs.version }} [skip ci]" | ||
| git push |
There was a problem hiding this comment.
When another PR is merged while this workflow is publishing, the checkout remains on the earlier push SHA and this plain git push cannot fast-forward over the newer main. The preceding publish step has already created the beta release and updated the mirror, but the source version remains unchanged; the queued run then computes the same beta version and fails while trying to publish an existing release. Fetch and integrate the latest main, or derive/reserve the version without relying on a post-publication push.
Useful? React with 👍 / 👎.
|
@trangdoan982 is the goal of this PR to "Automatically add merged Obsidian issues to in-progress" or to cut an obsidian beta release? |
mdroidian
left a comment
mdroidian
left a comment
There was a problem hiding this comment.
I think there's an issue here with what's happening with the versions. It seems like the mirror package JSON is going to be behind. And it also seems like we're committing back a -beta version to main on the monorepo? Is this the intended behavior? It's not quite clear to me because the ticket, I thought, was adding issues to in-progress Linear releases but this is dealing with beta version releases as well.
Could you double check when/where the versions change and create a video walkthrough of what the full intent is here, please?
…ar release Add obsidian-main.yaml: on every merge to main touching apps/obsidian, cut a beta GitHub release and sync the merged PR/issue onto whichever Linear release is currently in progress, mirroring how roam-main.yaml already does this for Roam. Depends on ENG-1767's publish.ts version write-back to compute the next beta number from an accurate baseline. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same reasoning as the stable workflow: GitHub Actions forces "implicit" mode via SUPABASE_URL/SUPABASE_PUBLISHABLE_KEY regardless of SUPABASE_USE_DB, so the variable had no effect here either. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Two PRs merging to main in quick succession would otherwise both compute the same next beta version off the same package.json read, racing to publish the same version and push conflicting version-bump commits. Concurrency group queues runs one at a time instead. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
6d9e9f7 to
a31c20b
Compare
|
Rebased onto the latest To answer your question: yes, both behaviors are intentional in the same workflow. Every push to The mirror |
…idian mirror Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
When a PR is merged while the beta-release workflow is running, the plain git push fails (non-fast-forward). Fetching and rebasing onto origin/main before the push makes the workflow resilient to concurrent merges. If the rebase conflicts (manual version edit), abort and skip the push gracefully — the release already exists and the version file self-corrects on the next run. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2 participants
Summary
obsidian-main.yaml: on every push tomaintouchingapps/obsidian/**, compute the next beta version, publish a-beta.nrelease viapublish.ts, commit the version bump back ([skip ci]), and sync the merged PR/issue onto whichever Linear release is currently in progress — mirroring howroam-main.yamlalready does this for Roamapps/obsidian/README.mdStacked on #1253 (ENG-1767) — depends on its
publish.tsversion write-back fix to compute the next beta number from an accurate baseline. Base branch iseng-1767-setup-linear-release-for-obsidian-v2, notmain; this should be merged after (or with) that 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."
Our new workflows only live on feature branches right now, so GitHub won't let us dispatch/test them yet. Once #1253 merges, we can trigger and iterate on them directly.
js-yamlparse check on the new workflow YAML-beta.1,-beta.N→-beta.N+1)apps/obsidian/**and confirm: beta release appears on GitHub, mirror repo (discourse-graph-obsidian) gets updated, version bump commits back tomainwithout retriggering itself, and Linear's in-progress release picks up the synced issue