ENG-1767 Setup Linear release for Obsidian

[trangdoan982]

https://www.loom.com/share/1c2c8bbce50a4d3d8cfe727c2d5edfb3

Summary

• add a manual Obsidian release workflow that syncs releases to Linear, runs the existing apps/obsidian/scripts/publish.ts flow, and updates the Linear stage to Sent to Obsidian for Review
• set required CI environment variables for the publish flow, including SUPABASE_USE_DB=production, and keep monorepo include_paths filtering for Linear sync
• add a companion manual workflow to complete an Obsidian Linear release by version

Test plan

• run Publish Obsidian Plugin from GitHub Actions with a test version and verify Sync Linear release succeeds
• verify the publish step runs successfully and creates/updates release artifacts in the Obsidian plugin repo
• verify Mark Linear release sent to Obsidian review updates the target release stage in Linear
• run Complete Obsidian Linear Release with the same version and verify the release is marked complete in Linear

Made with Cursor

[linear-code]

ENG-1767

[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 ↗︎.

[mdroidian]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4424c07f5c

ℹ️ 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".

[chatgpt-codex-connector]

Set post-publish Linear stage to review

This workflow updates the Linear release to Released immediately after running publish, which prematurely marks the release as shipped even though a separate obsidian-release-complete.yaml manual completion flow was added for finalization. In practice this bypasses the intended review gate (analogous to the Roam flow’s “Sent to … for Review” stage) and can cause release tracking in Linear to report production release before Obsidian review is actually complete.

Useful? React with 👍 / 👎.

[mdroidian]

I want to clarify the intended release flow here.

It sounds like we may be cutting a Linear release and /discourse-graph-obsidian release for every PR/feature. Is that correct? I’m assuming this is only for BRAT, not the Obsidian marketplace.

That would differ from the current Roam <> Linear flow, where each PR/feature is tagged with the current release, then when we cut a Roam Depot release, we update the Linear release status to indicate the collected work is being shipped.

Ideally, Roam and Obsidian should follow the same release pattern unless there’s a specific reason they need to differ.

Could you clarify:

• What is the expected process for sending an update to the Obsidian marketplace vs BRAT, especially given the new Obsidian community / AI review process?
• How do the Obsidian release YAMLs differ from the Roam release YAMLs, and why?
• If we cut a Linear release for every PR, how does the team know whether something is going to the Obsidian marketplace vs only to BRAT?
• In the video, you mentioned “release complete YAML here, which is called from Linear.” Where/how is that called from Linear?
• Where does the version number come from, and when/how is it updated?

A doc similar to apps/roam/RELEASE.md would probably help make this flow explicit.