Skip to content

Run CI on the Version Packages PR, and stop the version script rewriting Cargo.lock #1044

Description

@auxesis

The Version Packages PR is the last PR before every npm release from cipherstash/stack. No CI runs on it, and its approval can predate its final content.

No workflow runs on the Version Packages PR

release.yml opens and updates the Version Packages PR with changesets/action, which pushes with GITHUB_TOKEN. GitHub does not start workflows for a push made with GITHUB_TOKEN. So none of the repository's CI runs on that PR.

On 2 October 2026, #1020 had one check, the Dependabot configuration check. It released @cipherstash/auth 0.44.1 and the stack family 1.2.1 with no test run on its final commit, 1487a1aa. Earlier Version Packages PRs, such as #928, had CI only because a person pushed a commit to them.

Approval does not reset when the PR changes

changesets/action rewrites the PR whenever a changeset reaches main. freshtonic approved #1020 at bb8d2f0a. The bot then added the changeset from #1010, and #1020 merged at 1487a1aa with that approval still counted.

The version script rewrites protect-ffi's Cargo.lock

#1020 changed one line in languages/typescript/packages/protect-ffi/Cargo.lock: winapi-util moved from windows-sys 0.48.0 to 0.52.0. Nothing in the release asked for that.

On every release, scripts/sync-lockstep-versions.mjs runs cargo update --package eql-bindings in each workspace that locks eql-bindings from a path. It runs even when EQL's version does not change, as in #1020. Its own comment says that command "re-resolves the whole graph and rewrites a complete lock". main's lock passed cargo metadata --locked before #1020, so the lock was not stale. A likely cause is that the release job's Cargo, from packages/eql/mise.toml, resolves the windows-sys edges differently from the Cargo that wrote the lock. This is not yet confirmed.

Fix

  1. Give changesets/action a GitHub App installation token, made with actions/create-github-app-token, in place of GITHUB_TOKEN. GitHub starts workflows for an App's pushes. Keep commitMode: 'github-api', so the commits stay signed.
  2. Decide whether a new push to the Version Packages PR should dismiss its approval. If the ruleset should not do this for every PR, a check could fail when the approved commit is not the head.
  3. Skip cargo update when the eql-bindings version does not change. Then find out why the update rewrites the windows-sys edge. If the cause is the toolchain, run it with the same Rust that wrote the lock.

Done when

  • The next Version Packages PR runs the full CI on its head commit.
  • A release that does not bump EQL leaves every Cargo.lock unchanged.

Progress on 3 October 2026

Still to do

  1. Part 1 needs a GitHub App. An administrator installs a GitHub App on cipherstash/stack, with these repository permissions: Contents read and write, Pull requests read and write, and Metadata read. Then they add its client ID as a repository variable, and its private key as a repository secret. After that, the workflow change is small.
  2. Part 2 needs a decision. Choose one rule:
    • dismiss stale reviews when someone pushes, for every PR into main;
    • require approval of the most recent push, for every PR into main;
    • a required check, scoped to the Version Packages PR, that fails unless an approval names the head commit. This needs part 1 first.

Activity

  1. added
    bugSomething isn't working
    github-actionsPull request modifies GitHub Actions
    on Oct 3, 2026
  2. auxesis commented on Oct 5, 2026

    @auxesis
    ContributorAuthor

    Reopening. The Linear sync closed this issue on 4 October 2026, but two parts remain: a GitHub App token, so that CI runs on the Version Packages PR, and a rule so that approvals stay current after a bot push. #1028, #1029 and #1030 fixed the other parts. Version Packages PR #1054 shows the gap: no CI ran on it until someone closed and reopened it.

  3. reopened this on Oct 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    SDKbugSomething isn't workinggithub-actionsPull request modifies GitHub Actions

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions