[WIP] Update release publishing pipeline to trigger on workspace branch

[Copilot]

Thanks for asking me to work on this. I will get started on it and keep this PR's description up to date as I form a plan and make progress.

Problem

The release-publishing pipeline in this repo is hardwired to the main branch. When a release PR (e.g. #5254 bazel: Release v0.4.13.post0, base workspace) is merged into the workspace branch, nothing gets published because:

1. The artifact-producing CI workflows only trigger on push to main:

   • .github/workflows/bazel.yml, .github/workflows/docker.yml, .github/workflows/actions.yml, .github/workflows/py.yml, .github/workflows/rust.yml all have:

     on:
       pull_request:
       push:
         branches:
         - main

   (Verify each of these files — some may differ slightly; apply the same treatment to every workflow that _publish.yml lists under workflows: / artifact-workflows:: Bazel CI, Docker CI, Github/actions CI, Python CI, Rust CI.)

2. .github/workflows/publish.yml (Publish release) is triggered by workflow_run of those workflows and gated on github.event.workflow_run.event == 'push', so without a push-triggered run on workspace it always skips.

3. .github/workflows/_publish_release.yml hardcodes the checkout branch:

   - id: checkout
     name: Checkout the repository
     uses: envoyproxy/toolshed/actions/github/checkout@23d5a687b43f8984a3fdfd9b494470d80369b538  # actions-v0.4.26
     with:
       branch: main
       committer-name: ${{ inputs.committer-name }}
       committer-email: ${{ inputs.committer-email }}
       config: |
         ref: ${{ inputs.sha }}
       pr: ${{ inputs.event == 'pull_request' && github.event.pull_request.number || '' }}
       token: ${{ steps.appauth.outputs.token }}

   The branch is what the post-release "prepare dev" bump commit (via prepare-dev scripts such as .github/workflows/prepare_bazel_dev.sh) gets pushed to, so releasing from workspace would push the dev bump to main.

4. .github/workflows/_release.yml also hardcodes branch: main in its checkout step and base: main in the Create Pull Request step. (A separate PR against main is addressing this by using ${{ github.event_name == 'workflow_dispatch' && github.ref_name || 'main' }}; apply the same change here on workspace so the branches don't diverge.)

Required changes (target branch: workspace)

Make the pipeline branch-aware so that pushing to workspace publishes releases exactly as pushing to main does, with the post-release dev bump landing back on workspace.

A. Trigger CI on push to workspace

For each of bazel.yml, docker.yml, actions.yml, py.yml, rust.yml (and any other workflow named in _publish.yml's workflows: list), add workspace to on.push.branches:

on:
  pull_request:
  push:
    branches:
    - main
    - workspace

Check whether jq.yml or others are also dependencies of the publish flow (_publish.yml matrix artifact-workflows) and include them if so. Do not add workspace to unrelated workflows (lint, codeql, scorecard, etc.) unless required.

B. Thread the branch through the publish workflows

• In .github/workflows/_publish.yml, add a new workflow_call input:

  branch:
    default: ${{ github.event.workflow_run.head_branch }}
    type: string

  and pass branch: ${{ inputs.branch }} to the _publish_release.yml call.
• In .github/workflows/_publish_release.yml, add a matching branch input (type: string, default ${{ github.event.workflow_run.head_branch }}) and change the checkout step to branch: ${{ inputs.branch || 'main' }}.
• In .github/workflows/publish.yml, no change should be strictly needed if the default resolves from workflow_run.head_branch, but verify; if the default expression cannot be evaluated in a workflow_call input default, explicitly pass branch: ${{ github.event.workflow_run.head_branch }} from publish.yml.
• .github/workflows/publishing.yml (the PR dry-run test harness) calls _publish.yml with dry-run: true; ensure it still works (pass branch: main explicitly or rely on fallback). Do not break the dry-run tests.

C. Align _release.yml with the main-branch fix

In .github/workflows/_release.yml:

     - id: checkout
       with:
-        branch: main
+        branch: ${{ github.event_name == 'workflow_dispatch' && github.ref_name || 'main' }}
@@
     - name: Create Pull Request
       with:
-        base: main
+        base: ${{ github.event_name == 'workflow_dispatch' && github.ref_name || 'main' }}

D. Review the release action's branch assumptions

Inspect actions/github/release/action.yml (and anything it calls, e.g. actions/github/release/latest, prepare-dev handling, and the github/checkout action's branch semantics) to confirm the dev-bump commit is pushed to the checked-out branch and not to a hardcoded main. If there is any other hardcoded main on the publish path (including prepare_bazel_dev.sh / prepare_python_dev.sh), parameterize it the same way. Note: the workflows pin envoyproxy/toolshed/actions/*@23d5a687..., so changes to actions/ in this repo won't take effect until a new actions release; if a fix is needed inside the pinned actions, document it clearly in the PR description rather than silently relying on it.

Constraints

• Keep changes minimal and consistent with existing style (2-space indent, >- folded scalars, pinned action SHAs unchanged).
• Do not modify version files or anything under bazel/, py/, docker/ etc.
• Ensure all YAML remains valid.
• In the PR description, summarize the end-to-end flow for a workspace release after this change: merge release PR → push to workspace → CI workflows run (push event) → Publish release fires → release created from workspace sha → dev bump pushed to workspace.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: https://github.com/envoyproxy/toolshed/actions/runs/34862198778

this ci is supposed to open a pr on the workspace branch and handle the version from there (i ran it from that branch) - why did it not??

Assistant: The workflow did open a PR — #5250 (bazel: Release v0.4.16, head release/create/bazel/0.4.16, base main) — but it was cut from main, not from your workspace branch. That's because _release.yml hardcodes main in two places, so the branch you dispatched from is irrelevant:

    - id: checkout
      name: Checkout the repository
      uses: envoyproxy/toolshed/actions/github/checkout@23d5a687b43f8984a3fdfd9b494470d80369b538  # actions-v0.4.26
      with:
        branch: main
        committer-name: ${{ inputs.committer-name }}
        committer-email: ${{ inputs.committer-email }}
        pr: ${{ github.event.pull_request.number || '' }}
        token: ${{ steps.appauth.outputs.token }}

    - name: Create Pull Request
      uses: envoyproxy/toolshed/actions/github/pr@23d5a687b43f8984a3fdfd9b494470d80369b538  # actions-v0.4.26
      if: fromJSON(steps.commit.outputs.changes)
      with:
        base: main
        branch: >-
          release/${{ ... }}/${{ inputs.type }}/${{ ... }}

So the run checked out main, read bazel/VERSION.txt from main, bumped it there, and targeted main — your workspace branch's version was never seen. Running workflow_dispatch from a branch only changes which workflow file is used (github.ref), not what gets checked out, since the checkout ignores github.ref.

Fix: use the dispatched ref instead of hardcoded main (with main as fallback so Releasing CI's pull_request-triggered dry-runs keep behaving):

     - id: checkout
       name: Checkout the repository
       uses: envoyproxy/toolshed/actions/github/checkout@23d5a687b43f8984a3fdfd9b494470d80369b538  # actions-v0.4.26
       with:
-        branch: main
+        branch: ${{ github.event_name == 'workflow_dispatch' && github.ref_name || 'main' }}
@@
     - name: Create Pull Request
       uses: envoyproxy/toolshed/actions/github/pr@23d5a687b43f8984a3fdfd9b494470d80369b538  # actions-v0.4.26
       if: fromJSON(steps.commit.outputs.changes)
       with:
-        base: main
+        base: ${{ github.event_name == 'workflow_dispatch' && github.ref_name || 'main' }}

Alternatively add an explicit branch/base input to release.yml → _release.yml if you'd rather it be opt-in. Note the PR branch name (release/create/bazel/<version>) would also need a suffix (or use the base branch name) if you want concurrent releases from different base branches to not collide.

Want me to…

1. Hand this change off to the coding agent to open a pull request
2. Make it an explicit base-branch input on release.yml (defaulting to main) instead of deriving it from github.ref_name
3. Also make the release branch name include the base branch to avoid collisions between main and workspace releases

User: add a pr against main to ensure that it raises against the ci branch

Assistant: I've queued the coding agent handoff to open a PR against main in envoyproxy/toolshed with the _release.yml change — waiting for you to confirm the tool call before it starts.

User: @copilot Accepted Confirmation: Confirm cloud agent session

Assistant: The Copilot coding agent has started working on this. It will open a PR against main in envoyproxy/toolshed that replaces the hardcoded main in _release.yml (both the checkout branch and the PR base) with ${{ github.event_name == 'workflow_dispatch' && github.ref_name || 'main' }}, so a dispatch from your workspace branch will check out and raise the release PR against that branch.

Track progress here: https://github.com/envoyproxy/toolshed/tasks/2a45b25b-444c-4b1e-b263-bef0db7e3fba

Once merged, re-dispatching Release from the workspace branch should read bazel/VERSION.txt from that branch and open the release/create/bazel/<version> PR targeting it.

User: k - so if i land this - will it publish as expected ??

@envoyproxy/toolshed/pull/5254

Assistant: No — landing #5254 into workspace will not publish anything. The publish pipeline is wired exclusively to main:

1. Bazel CI only runs on push to main — merging to workspace produces no push-triggered CI run, only pull_request runs while the PR is open.

on:
  pull_request:
  push:
    branches:
    - main

2. Publish release is gated on workflow_run.event == 'push' — so it needs that main-push Bazel CI run to exist, and would skip otherwise (this is exactly why you're seeing all those skipped "Publish release" runs in the runs list).

jobs:
  publish:
    if: >-
      github.event.workflow_run.event == 'push'

3. _publish_release.yml also hardcodes branch: main for its checkout (same issue as _release.yml), and the post-release "prepare dev" bump commit would be pushed to main, not workspace.

    - id: checkout
      name: Checkout the repository
      uses: envoyproxy/toolshed/actions/github/checkout@23d5a687b43f8984a3fdfd9b494470d80369b538  # actions-v0.4.26
      with:
        branch: main
        ...
        config: |
          ref: ${{ inputs.sha }}

One more thing to check on the PR itself: the version is 0.4.13.post0, meaning bazel/VERSION.txt on workspace is at 0.4.13-dev-ish while main is already past 0.4.16. A bazel-v0.4.13.post0 tag/release would be a "release" that's older than the current main one — probably fine if that's intentional for the workspace line, but worth being explicit about.

To make publishing from workspace work you'd need at minimum: add workspace to the push.branches of the relevant CI workflows (bazel.yml and the others listed in _publish.yml's workflows:), and replace branch: main in _publish_release.yml with the workflow_run.head_branch (e.g. ${{ github.event.workflow_run.head_branch || 'main' }} threaded through _publish.yml as an input). You'd also need to decide if the prepare-dev bump commit and release/latest lookups should be branch-aware.

Want me to…

1. Hand off a follow-up to the coding agent that makes the publish pipeline branch-aware (push triggers on workspace, head_branch threaded into _publish_release.yml)
2. Check what the current main vs workspace bazel versions/tags are so the 0.4.13.post0 release doesn't collide with existing tags
3. Trace exactly what the github/release action does with version-file / prepare-dev to confirm where the post-release commit would land

User: raise a pr against workspace branch to address - ill land before the publish pr

Assistant: The coding agent handoff (PR against workspace to make the publish pipeline branch-aware) is queued — waiting for you to confirm the tool call before it starts.