Prepare v0.13.0 release

.buildkite/pipeline.yml

@@ -44,7 +44,7 @@ steps:
           plugins:
             - github-actions#$$commit:
                 workflow: .buildkite/fixtures/plugin-release-linux.yml
-                version: 0.13.7
+                version: 0.17.0
                 experimental-runner-user: true
                 runners:
                   - runs-on: ubuntu-latest
@@ -65,7 +65,7 @@ steps:
             - github-actions#$$commit:
                 workflows:
                   - .buildkite/fixtures/plugin-release-mixed.yml
-                version: 0.13.7
+                version: 0.17.0
                 runners:
                   - runs-on: ubuntu-latest
                     queue: hosted
@@ -84,7 +84,7 @@ steps:
             - github-actions#$$commit:
                 workflows:
                   - .buildkite/fixtures/plugin-release-macos.yml
-                version: 0.13.7
+                version: 0.17.0
                 runners:
                   - runs-on: macos-14
                     queue: macos

DEVELOPMENT.md

@@ -27,7 +27,7 @@ The Bats suite makes no live network requests. CI runs these checks plus the Bui
 The Buildkite Pipelines build runs required released-runtime smoke tests that:
 
 - Pins the plugin to the build's full public commit SHA.
-- Pins `buildkite-gha` v0.13.7 through mise.
+- Pins `buildkite-gha` v0.17.0 through mise.
 - Runs Linux-only default-image and explicit-image jobs with the experimental `runner` user, a mixed Linux-to-macOS graph, and a macOS-only graph.
 
 These tests use Linux x86-64 and native macOS arm64 Buildkite hosted agents without configured secrets or a cache service.

README.md

@@ -3,7 +3,7 @@
 > [!NOTE]
 > Running GitHub Actions workflows in Buildkite is currently in public preview. To report issues with the preview, [open an issue in the `buildkite-gha` repository](https://github.com/buildkite/buildkite-gha/issues). For help migrating to native Buildkite Pipelines steps, contact the [Buildkite Support team](mailto:support@buildkite.com).
 >
-> The plugin and runtime are under active development. Review the [`buildkite-gha` v0.12.1 compatibility guide](https://github.com/buildkite/buildkite-gha/blob/v0.12.1/docs/compatibility.md) before adding a workflow.
+> The plugin and runtime are under active development. Review the [`buildkite-gha` v0.17.0 compatibility guide](https://github.com/buildkite/buildkite-gha/blob/v0.17.0/docs/compatibility.md) before adding a workflow.
 
 The GitHub Actions Buildkite plugin converts a supported [GitHub Actions workflow](https://docs.github.com/en/actions/using-workflows/about-workflows) into native [Buildkite Pipelines](https://buildkite.com/docs/pipelines) jobs without creating a GitHub Actions workflow run. This lets you start migrating a workflow before [converting it into native Buildkite Pipelines steps](https://buildkite.com/docs/pipelines/migration/from-githubactions).
 
@@ -26,7 +26,7 @@ steps:
 
 The selector must be an explicit path to a tracked `.yml` or `.yaml` workflow file. When this importer step runs, the plugin uploads one dynamic pipeline containing a Buildkite group for each directly runnable workflow. Each workflow job and static matrix entry becomes a Buildkite Pipelines job that depends on the importer step. The importer step must have a `key` and must be scheduled explicitly on either a Linux amd64 or native macOS arm64 agent. The plugin's `runners` mappings schedule generated workflow jobs only; they do not select or change the importer agent.
 
-The Git ref after `github-actions#` selects the plugin code. Use a specific release such as `github-actions#v0.12.0` for an immutable pin, or use `github-actions#latest` to follow the newest stable plugin release that has passed the required validation. This is separate from the `version` property below, which selects the `buildkite-gha` runtime.
+The Git ref after `github-actions#` selects the plugin code. Use a specific release such as `github-actions#v0.13.0` for an immutable pin, or use `github-actions#latest` to follow the newest stable plugin release that has passed the required validation. This is separate from the `version` property below, which selects the `buildkite-gha` runtime.
 
 Configure runtime selection with the following properties:
 
@@ -85,7 +85,7 @@ steps:
     plugins:
       - github-actions#latest:
           workflow: .github/workflows/ci.yml
-          version: "0.13.7"
+          version: "0.17.0"
           experimental-runner-user: true
           runners:
             - runs-on: ubuntu-latest
@@ -224,10 +224,10 @@ Pull request builds receive `pull_request` context. Branch and tag builds receiv
 
 Supported, audited `actions/checkout` revisions can check out the exact event repository and commit from `github.com`. Checkout runs anonymously when repository-provider credentials are not enabled. Private checkout uses Buildkite repository-provider Git credentials when they are enabled and authorized for the job.
 
-Checkout credentials do not populate `GITHUB_TOKEN` or `github.token`, enable private actions, or allow alternate repositories or refs. A workflow can receive a temporary GitHub token only when it makes a supported static token reference and both the Buildkite organization feature and the pipeline's default-off token setting are enabled. When the workflow omits `permissions`, the runtime requests exactly `contents: read` without inheriting GitHub repository or organization defaults. Write access requires an explicit top-level permissions map; an empty map or scopes set to `none` mint no token. The compatibility guide describes the [complete credential boundary](https://github.com/buildkite/buildkite-gha/blob/v0.12.1/docs/compatibility.md#repositories-credentials-and-github-services).
+Checkout credentials do not populate `GITHUB_TOKEN` or `github.token`, enable private actions, or allow alternate repositories or refs. A workflow can receive a temporary GitHub token only when it makes a supported static token reference and both the Buildkite organization feature and the pipeline's default-off token setting are enabled. When the workflow omits `permissions`, the runtime requests exactly `contents: read` without inheriting GitHub repository or organization defaults. Write access requires an explicit top-level permissions map; an empty map or scopes set to `none` mint no token. The compatibility guide describes the [complete credential boundary](https://github.com/buildkite/buildkite-gha/blob/v0.17.0/docs/compatibility.md#repositories-credentials-and-github-services).
 
 > [!WARNING]
-> Temporary token issuance verifies the workflow and build provenance. Job-level permissions and reusable-workflow jobs are rejected, pull request ancestry is capped at `contents: read`, and merge queue ancestry is denied. Review the workflow-token restrictions before enabling the service.
+> Temporary token issuance verifies the workflow and build provenance. Job-level permissions are rejected. Jobs expanded from local reusable workflows use the top-level requesting workflow's repository permissions because called-workflow permission maps do not narrow `GITHUB_TOKEN`. Pull request ancestry is capped at `contents: read`, and merge queue ancestry is denied. Review the workflow-token restrictions before enabling the service.
 
 ## Cache mise installations
 
@@ -270,10 +270,10 @@ Important limitations include:
 - The complete `github.event` payload and GitHub-specific event behavior are not available at runtime.
 - Unaudited revisions of actions with native support are rejected.
 
-If a feature is not listed in the [`buildkite-gha` v0.12.1 compatibility guide](https://github.com/buildkite/buildkite-gha/blob/v0.12.1/docs/compatibility.md), treat it as unsupported.
+If a feature is not listed in the [`buildkite-gha` v0.17.0 compatibility guide](https://github.com/buildkite/buildkite-gha/blob/v0.17.0/docs/compatibility.md), treat it as unsupported.
 
 > [!WARNING]
-> All steps in an imported job share a workspace, environment changes, processes, and action lifecycle. Docker actions provide packaging, not a security boundary. Review the [`buildkite-gha` v0.12.1 security model](https://github.com/buildkite/buildkite-gha/blob/v0.12.1/docs/security.md) before running untrusted workflow code.
+> All steps in an imported job share a workspace, environment changes, processes, and action lifecycle. Docker actions provide packaging, not a security boundary. Review the [`buildkite-gha` v0.17.0 security model](https://github.com/buildkite/buildkite-gha/blob/v0.17.0/docs/security.md) before running untrusted workflow code.
 
 ## Develop the plugin