-
Notifications
You must be signed in to change notification settings - Fork 89
ci: sync published production releases to Linear scheduled pipeline #30622
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,101 @@ | ||
| # Linear Release sync — connects published production releases of this repo | ||
| # to Linear's release tracking so issues referenced in commit/PR titles between | ||
| # the previous tagged release and the current one are automatically grouped | ||
| # under the new release. | ||
| # | ||
| # This repo follows a tagged-release model (semver tags like `v0.5.3`), so the | ||
| # Linear pipeline configured to consume this sync should be of type | ||
| # **Scheduled** — not Continuous. The companion repo | ||
| # `vellum-ai/vellum-assistant-platform` is continuously deployed and uses a | ||
| # separate Continuous pipeline (see that repo's `linear-release-sync.yml`). | ||
| # | ||
| # The action scans commit history between the previous Linear release and the | ||
| # tagged commit, extracts Linear issue identifiers (e.g. `LUM-1234`, | ||
| # `JARVIS-123`), and creates or updates a Scheduled release identified by the | ||
| # git tag. | ||
| # | ||
| # Filtering: only true production releases (clean semver tags such as | ||
| # `v0.5.3`) advance the pipeline. The repo's release workflow also publishes | ||
| # `-staging.N` pre-release tags (`v0.7.4-staging.2`) via `gh release create`, | ||
| # and future workflows could plausibly publish other pre-release variants | ||
| # (`-rc.N`, `-beta.N`, `-alpha.N`). All such tags share the property that the | ||
| # semver-string contains a hyphen, so any tag with `-` in the suffix is | ||
| # skipped. This keeps Linear issues from being marked as shipped to | ||
| # production before they actually are. | ||
| # | ||
| # Setup prerequisites (one-time, in Linear and GitHub UIs): | ||
| # 1. Create a Scheduled release pipeline in Linear: | ||
| # Settings → Releases → New pipeline → Type: Scheduled. | ||
| # 2. Copy the pipeline access key from its settings page. | ||
| # 3. Add the access key as a GitHub Actions secret on this repo named | ||
| # `LINEAR_ACCESS_KEY` (Settings → Secrets and variables → Actions). | ||
| # | ||
| # References: | ||
| # - Linear — Releases: https://linear.app/docs/releases | ||
| # - linear/linear-release-action: https://github.com/linear/linear-release-action | ||
| # - Linear Release CLI (pipeline semantics): https://github.com/linear/linear-release | ||
| # - GitHub — `release` event: | ||
| # https://docs.github.com/en/actions/reference/events-that-trigger-workflows#release | ||
| name: Linear Release Sync | ||
|
|
||
| on: | ||
| release: | ||
| types: [published] | ||
|
|
||
| permissions: | ||
| contents: read | ||
|
|
||
| concurrency: | ||
| # Serialize so two releases published back-to-back can't race the action | ||
| # into creating overlapping releases for the same commit window. | ||
| group: linear-release-sync | ||
| cancel-in-progress: false | ||
|
|
||
| jobs: | ||
| sync: | ||
| name: Sync Linear release | ||
| runs-on: ubuntu-latest | ||
| # Skip on forks (the secret isn't available there) and on any pre-release | ||
| # tag (`vX.Y.Z-staging.N`, `vX.Y.Z-rc.N`, `vX.Y.Z-beta.N`, …). The repo's | ||
| # current release workflow publishes staging tags through the same | ||
| # `gh release create` path as production but encodes the channel in the | ||
| # tag suffix; the `prerelease` flag on the GitHub Release object is *not* | ||
| # set (no `--prerelease`), so we can't rely on | ||
| # `github.event.release.prerelease`. Filtering on a hyphen in the tag | ||
| # catches every pre-release shape semver allows and keeps | ||
| # Scheduled-pipeline releases aligned with actual production launches. | ||
| if: >- | ||
| github.repository == 'vellum-ai/vellum-assistant' && | ||
| !contains(github.event.release.tag_name, '-') | ||
| steps: | ||
| - name: Checkout release tag | ||
| uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2 | ||
| with: | ||
| # The published release's tag — checkout this exact ref so the | ||
| # action scans the commit history that actually shipped, not | ||
| # whatever HEAD happens to be on the default branch when the event | ||
| # fires. | ||
| ref: ${{ github.event.release.tag_name }} | ||
| # Full commit history required so the action can walk back from the | ||
| # release tag to the previous Linear release and find every issue | ||
| # mentioned in commit titles, merge commits, and PR titles in | ||
| # between. | ||
| fetch-depth: 0 | ||
|
|
||
| - name: Sync to Linear scheduled pipeline | ||
| uses: linear/linear-release-action@755d50b5adb7dd42b976ee9334952745d62ceb2d # v0.6.0 | ||
| with: | ||
| access_key: ${{ secrets.LINEAR_ACCESS_KEY }} | ||
| # For scheduled pipelines, the Linear Release CLI recommends always | ||
| # passing `version` in CI so the sync targets the exact Linear | ||
| # release matching this git tag instead of inferring from | ||
| # started/planned state. See "Command targeting" in the action's | ||
| # README. | ||
| version: ${{ github.event.release.tag_name }} | ||
| # Pin the underlying Linear Release CLI version. The action's input | ||
| # defaults to `latest`, which would let every production run pull a | ||
| # newer CLI build with potentially-changed behavior or flags. To | ||
| # upgrade: look up the new CLI tag at | ||
| # https://github.com/linear/linear-release/releases and bump the | ||
| # value below in the same PR as the action SHA bump. | ||
| cli_version: v0.10.0 | ||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I checked
linear/linear-release-actionv0.6.0: itscli_versioninput defaults tolatest, and the README recommends pinning an exact tag for reproducible builds. Since this step pins the action SHA but omitscli_version, every production release can download a newer Linear Release CLI with changed behavior or flags without any repo change, which can break or alter the Linear sync unexpectedly; pass an explicit CLI version in thiswith:block.Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in 60798a7: pinned
cli_version: v0.10.0(the current default in the upstream README) so a future change to the action'slatestresolution can't silently alter the sync's behavior in production. Added an inline comment with the upgrade path (look up the new tag at https://github.com/linear/linear-release/releases, bump in the same PR as the action SHA bump). Resolved.