ENG-2099 Test and fix Obsidian Linear release pipeline

[trangdoan982]

Obsidian release pipeline: test report

https://www.loom.com/share/ebfdaee0363449a784fb7030c3bb0d02

Six bugs found. Five are fixed in code. Last one about updating versioning on package.json need discussion.
Note for reviewer: Easier to read through Github comments to see the bug overview first, then come back here for more details about testing and fixing of each bug

Terms used below

• publish repo: DiscourseGraphs/discourse-graph-obsidian, the public repo the Obsidian community store and BRAT read from
• test repo: DiscourseGraphs/discourse-graph-obsidian-test, created for this testing
• beta workflow: obsidian-main.yaml
• stable workflow: obsidian-release.yaml

How the tests were set up

publish.ts hardcodes the publish repo in three constants. I temporarily pointed those constants and both workflows' credentials at the test repo. Those are the commits on #1311 marked TEMP, each carrying a TODO(ENG-2099): REVERT BEFORE MERGE marker.

I triggered everything from the branch with workflow_dispatch. That runs the branch's copy of the workflow and script, and still has access to repo secrets:

gh workflow run obsidian-main.yaml --repo DiscourseGraphs/discourse-graph \
  --ref eng-2099-test-obsidian-linear-release-pipeline

Bug A (fixed): betas published as official releases and overwrote the store's manifest

isExternalRelease() returned true for beta as well as stable.

Fixed in 2f7a0ce7. Only a bare x.y.z counts as external now, so betas and alphas stay pre-releases and leave main alone.

Verification

I checked the classification against the edited source across fourteen inputs: stable, -beta.N, bare -beta, -alpha-name, -rc.N, plus malformed ones like 1.5, v1.5.2, empty, and abc. All fourteen behaved as intended. Two pre-existing quirks are harmless: 1.5.2.1 and 01.5.2 pass validateVersion, because its regex is not anchored at the end, and then classify as pre-releases instead of being rejected.

Then proven in five beta runs. Every beta came out as prerelease=true:

• 1.5.2-beta.1, run 32414296753
• 1.5.2-beta.2, run 32530988461
• 1.5.2-beta.3, run 32535166706
• 1.5.2-beta.4, run 32535400477
• 1.5.2-beta.5, run 32535403999

The decisive check is what those five runs did not do. After all of them, the test repo's main still had one commit and one file:

gh api repos/DiscourseGraphs/discourse-graph-obsidian-test/commits
  -> 4b58ca94 Initial commit

gh api "repos/.../git/trees/main?recursive=1"
  -> README.md

No manifest.json, no Release v... commit. Before the fix, each of those runs would have overwritten the store's manifest. GitHub also reported no "latest" release while only betas existed, which is the correct signal that a beta is not standing in for a stable release.

I confirmed each release's attached manifest.json asset carried the matching version and the right plugin id, by pulling the asset bytes rather than trusting the log:

gh api repos/.../releases/assets/<id> -H "Accept: application/octet-stream"
  -> version = 1.5.2-beta.3, id = discourse-graphs   (all five matched their tag)

Bug B (fixed): every run on main failed at the Linear step

The workflows referenced secrets.OBSIDIAN_LINEAR_RELEASE_KEY. That secret does not exist. The real name is LINEAR_RELEASES_ACCESS_KEY_OBSIDIAN, so the input resolved to an empty string and the action exited:

LINEAR_ACCESS_KEY:
##[error]access_key input is required

This is why it worked for me and failed for everyone else. The name was correct on the eng-1767 branch, which is why it passed there on 24 May, and it changed when that merged. Outcomes since:

gh run list --workflow obsidian-main.yaml --limit 60 --json conclusion
  -> {"cancelled": 3, "failure": 6}

Zero successes, ever, on main.

The part worth internalising: that step runs last, after publish has already written to the publish repo. Every one of those red runs still changed production. A failed run never meant "nothing shipped". It meant "shipped, then failed to tell Linear".

Fixed in all three references in 7b33e2d2, and confirmed live. The key resolves and the step passes.

Bug C (fixed): the beta counter never incremented

gh release list ran without --repo, so it queried the monorepo. The monorepo has no releases and no tags. The lookup always came back empty, and the code fell through to -beta.1 every time.

Fixed in 5eb67213 by pointing the lookup at the publish repo. I verified the shell logic locally against both repos before spending a run on it, then confirmed in sequence. The runs after the fix produced beta.2, beta.3, beta.4, and beta.5, each incrementing correctly.

Bug D (fixed): source files silently dropped from the publish repo

shouldExclude matched patterns with relativePath.includes(), and turned glob patterns into unanchored regexes. Any file whose name merely contained an excluded word was dropped. "out" ate DatacoreCallout.tsx. *.log became /.*.log/ and ate nativeJsonFileDialogs.ts via "diaLOGs".

Fixed in 1bb10ac7. Patterns now match whole path segments, and globs are anchored to a single segment with regex metacharacters escaped.

Verification

real publish, run 32539711072, commit 77f5b0d7:

src file count:  101 local -> 101 published   (was 99)
PRESENT  src/components/DatacoreCallout.tsx
PRESENT  src/utils/nativeJsonFileDialogs.ts

I re-ran the secret check against the enlarged set of 113 published files. No .env, secret, .pem, or credential files. .env, .env.branch, .env.example, nested .env.local, *.pem, *.log, node_modules, dist, scripts, and .git all stay excluded. Names that would previously have been landmines (Logger.ts, Layout.tsx, distance.ts, environment.ts, buildIndex.ts) are correctly kept.

Bug E (fixed): the published package.json was one release behind, permanently

There are two copies of the version, written at different times. updateManifest only rewrote manifest.json in the staging directory. package.json was copied at its pre-bump value, and updateLocalVersion, which does bump it, runs after updateMainBranch has already pushed.

Observed on both repos:

test repo, right after publishing 9.9.9:  manifest.json = 9.9.9         package.json = 1.5.2
publish repo:                             manifest.json = 1.5.2-beta.1  package.json = 1.5.2

Low user impact, since Obsidian reads manifest.json. It mattered because the published repo contradicted itself, and anything reading package.json got the wrong answer.

Fixed in 07180a4d with an updateStagedPackageVersion step that runs alongside updateManifest, before the push. Verified on the same 9.9.10 publish:

manifest.json: 9.9.10
package.json:  9.9.10

Bug F: stable workflow can't run step "Commit version bump"

main is protected by a ruleset, not by classic branch protection. That is why it reads as protected but the protection endpoint returns 404:

gh api repos/DiscourseGraphs/discourse-graph/rulesets
  -> "Main Branch Protection"  target=branch  enforcement=active
     rules:  pull_request, non_fast_forward
     bypass: OrganizationAdmin only

github-actions[bot] is not a bypass actor, so the Commit version bump step's git push is rejected whenever the workflow runs from main. The step sits after publishing, so a real stable release would create the GitHub release, push the publish repo, then fail, and never reach the Linear steps.

Retrying does not help. updateMainBranch reports no changes, createGithubRelease skips the existing release, updateLocalVersion rewrites the same two files, and the push is rejected again. The Linear half of the pipeline was unreachable for that version, permanently.

Options:

1. Comment out this code in c4a86fc5. We just don't care about updating versioning in monorepo, only care about versioning in discourse-graph-obsidian
2. add permission to github-actions. But this introduce potential security risks.

The stable workflow, tested

I dispatched it twice, both times with a deliberately fake version. That kept it from colliding with anything real, and kept the Linear complete command away from the genuine 1.5.4 release:

gh workflow run obsidian-release.yaml --repo DiscourseGraphs/discourse-graph \
  --ref eng-2099-test-obsidian-linear-release-pipeline -f version=9.9.9

First run, 32537199051. All ten steps green, the first time this workflow has run since May. It produced release 9.9.9 with prerelease=false and all three assets, and GitHub promoted it to "latest". The contrast with the five betas is exactly what we want. The push landed commit 150d5286 with 111 files. This run exposed Bugs D and F.

Second run, 32539711072, verifying those two fixes. It produced release 9.9.10, again prerelease=false with all three assets and promoted to "latest", and commit 77f5b0d7 with 113 files. The two extra files are the ones Bug D had been eating.

On the security question: across all 113 published files there are no .env, secret, .pem, or credential files, and package.json had its scripts block stripped as intended.

Both Linear commands worked in both runs. sync found the commit range and synced. complete advanced the release to Released.

• 9.9.9 to Linear release 6803609662b6
• 9.9.10 to Linear release 7a5dc916-0ee6-4dca-a0fb-2b496d8b18fa, logging Found 4 matching commits between 8d68b05 and 2dc6982

Two things about Linear to flag:

• The workflow input says the version "must match an existing Linear release version", but nothing validates that. sync created brand new releases for both 9.9.9 and 9.9.10, each named "New release", and complete marked them Released. A typo will invent a release rather than fail.
• The log line issues [ENG-2099] did not translate into anything. The 9.9.9 release ended with issueCount: 0. Do not read that log line as proof that issue attribution works.

Separately, one beta run's Linear sync correctly did nothing:

Found 0 matching commits ... Skipping release creation.

The only commit in range touched .github/, which is outside include_paths. That is right, and it is good evidence the path filtering works. It also means the GitHub release and the Linear release can legitimately diverge while the step reports success.

Concurrency: fast merges skip betas

Three dispatches fired back to back produced one running, one cancelled, one queued. With cancel-in-progress: false, GitHub keeps only one pending run per concurrency group, so a third arrival kills the waiting second:

32535403999  pending
32535402204  cancelled     <- killed by the run behind it
32535400477  in_progress

The two survivors computed beta.4 and beta.5 correctly, so there is no race in the version lookup. The queue serialises properly.

This is the mechanism behind the three cancelled runs on main, and it means rapid merges do not each produce a beta. Not a bug, but not obvious either. Worth deciding whether it is what we want.

Mine to finish:

• Revert the four TEMP commits on ENG-2099 Test and fix Obsidian Linear release pipeline #1311 and take it out of draft.
• Revert the two bot version bumps, 8776c607 for 9.9.9 and 2dc69828 for 9.9.10. They leave apps/obsidian/package.json and manifest.json at 9.9.10 on the branch. This must not merge carrying a 9.9.x version.
• Clean up test artifacts:
  • delete the test repo
  • the two Linear "New release" entries for 9.9.9 and 9.9.10, the eight test repo releases, and the stale Linear release "New release" from 24 May that has no version and still sits In Progress.

[linear-code]

ENG-2099

[supabase]

This pull request has been ignored for the connected project zytfjzqyijgagqxrzbmz because there are no changes detected in packages/database/supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.

---

Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
discourse-graph	Ready	Preview	Aug 22, 2026 4:07am

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.

[trangdoan982]

Bug A: -beta versions were published as official releases

This predicate returned true for beta as well as stable, and one boolean gated two separate decisions: the GitHub prerelease flag, and whether to push manifest.json to the publish repo's main branch. So a beta shipped as a full release, and it overwrote the manifest the Obsidian community store reads to pick a version. That is ENG-2106.

The publish repo's main still sits at 1.5.2-beta.1 today, with five Release v1.5.2-beta.1 commits, two of them landing after stable 1.5.3 shipped on 7 Aug.

Verified across fourteen version inputs, then in five beta runs: every release came out prerelease=true, and the test repo's main kept exactly one commit and one file throughout.

[trangdoan982]

Bug B: every run on main failed at the Linear step

This referenced secrets.OBSIDIAN_LINEAR_RELEASE_KEY, which does not exist. The real secret is LINEAR_RELEASES_ACCESS_KEY_OBSIDIAN, so the input resolved to an empty string and the action exited with access_key input is required.

The name was correct on eng-1767, which is why it passed there on 24 May, and it changed on merge. Since then: 6 failures, 3 cancelled, 0 successes.

Worth noting the step runs last, after publish has already written to the publish repo. Those red runs still changed production.

[trangdoan982]

Bug C: the beta counter never incremented

gh release list ran without --repo, so it queried the monorepo, which has 0 releases and 0 tags. The lookup always came back empty and the code fell through to -beta.1 every time.

The failure mode was the quiet kind: the recomputed version already existed, createGithubRelease took its early return, and the run exited green having shipped nothing.

After the fix the runs produced beta.2 through beta.5, incrementing correctly.

[trangdoan982]

Bug D: source files were silently dropped from the publish repo

The old matcher used relativePath.includes(pattern) and turned globs into unanchored regexes, so any file whose name merely contained an excluded word was dropped. "out" ate src/components/DatacoreCallout.tsx. *.log became /.*.log/ and ate src/utils/nativeJsonFileDialogs.ts via "diaLOGs".

Confirmed on a real publish: 101 local source files, 99 published. After the fix, 101 of 101.

Before committing I diffed old against new across the whole apps/obsidian tree: exactly those two files flip to included, nothing flips the other way. Re-checked secrets against the enlarged 113-file set, since loosening an exclusion filter on a public repo is where a leak would hide. Nothing sensitive published.

[trangdoan982]

Bug E: the published package.json was permanently one release behind

updateManifest only rewrote manifest.json in the staging directory. package.json was copied at its pre-bump value, and updateLocalVersion runs after updateMainBranch has already pushed.

Result on both repos:

test repo, right after publishing 9.9.9:  manifest.json = 9.9.9         package.json = 1.5.2
publish repo:                             manifest.json = 1.5.2-beta.1  package.json = 1.5.2

Low user impact, since Obsidian reads manifest.json, but the published repo contradicted itself. Verified on the 9.9.10 publish: both files now read 9.9.10.

[trangdoan982]

Bug E: this step could never succeed on main

The Main Branch Protection ruleset requires a pull request on the default branch and does not list github-actions[bot] as a bypass actor, so the push is always rejected there.

The step sits after publishing, so a real stable release would create the GitHub release, push the publish repo, then fail here and never reach the Linear steps. Retrying does not help: updateMainBranch reports no changes, createGithubRelease skips the existing release, updateLocalVersion rewrites the same files, and the push is rejected again. The Linear half of the pipeline was unreachable for that version.

The two green runs on 24 May prove nothing. They ran on a branch, where git push targets the branch instead of main.

The step's own git diff --quiet guard is what makes disabling it safe: bump the version in the release PR and there is nothing for CI to push. I did not reproduce the rejection, since that needs a real stable release from main.