ci: switch from SLSA provenance to actions/attest with subject-path

[keelerm84]

Requirements

• I have added test coverage for new or changed functionality
• I have followed the repository's pull request submission guidelines
• I have validated my changes against all supported platform versions

N/A — CI-only changes, no application code or tests affected.

Related issues

Supports the org-wide migration to immutable GitHub releases. Once immutable releases are enabled, artifacts can no longer be uploaded after a release is published. This repo only uses attestation (no binary/artifact uploads to the release), so actions/attest@v4 — which stores attestations via GitHub's attestation API rather than as release assets — is compatible with immutable releases without needing draft releases.

Describe the solution you've provided

Changes across four files:

1. release-please-config.json — Reformatted extra-files array to multi-line (no functional change).

2. .github/actions/publish/action.yml — Removed the gem-hash output and "Hash gem for provenance" step. These existed to produce base64-encoded checksums for the old SLSA generator and are no longer needed since attestation now uses subject-path directly.

3. .github/workflows/release-please.yml — In the publish job:

   • Replaced the separate release-provenance job (SLSA generator_generic_slsa3 reusable workflow with upload-assets: true) with an inline actions/attest@v4 step using subject-path: 'launchdarkly-server-sdk-*.gem'.
   • Added attestations: write permission.
   • Added fetch-depth: 0 to the checkout step.
   • Removed gem-hash from job outputs.
   • Removed orphaned upload-tag-name output (was only consumed by the now-removed release-provenance job). The release-created output is retained as it is still used by downstream jobs.

4. .github/workflows/manual-publish.yml — Same attestation migration:

   • Replaced the separate release-provenance job with an inline actions/attest@v4 step using subject-path gated on !inputs.dry_run.
   • Added attestations: write permission.
   • Removed gem-hash from job outputs.

Why subject-path instead of subject-checksums?

The previous approach used a base64 encode/decode round-trip inherited from the old SLSA generator: the composite action hashed artifacts and base64-encoded the checksums, then the workflow decoded them into a checksums file for actions/attest. Since actions/attest@v4 supports subject-path — which accepts file globs and computes checksums internally — the entire round-trip is eliminated. The glob launchdarkly-server-sdk-*.gem matches the built gem files directly on disk.

Why no draft releases?

The old SLSA generator uploaded .intoto.jsonl provenance files as release assets (via upload-assets: true), which would fail under immutable releases. The new actions/attest@v4 stores attestations via GitHub's attestation API instead — it does not modify the GitHub release. Since this repo has no other artifact uploads, the release can be published directly by release-please without a draft→publish flow.

Describe alternatives you've considered

• subject-checksums: An earlier revision decoded base64 hashes into a checksums file for actions/attest. This worked but was unnecessarily complex since the artifact files are already on disk in the same job.
• Draft release pattern: An earlier revision used draft releases with a publish-release job. Simplified since this repo only uses attestation, not artifact uploads.
• Keep SLSA generator: Could keep it as a separate reusable workflow, but actions/attest@v4 is the org-standard replacement and runs inline without requiring a separate job.

Additional context

⚠️ Items for reviewer attention:

• Glob pattern correctness: The subject-path: 'launchdarkly-server-sdk-*.gem' glob must match all gem files produced by the build (both CRuby and JRuby variants). The existing publish action already uses the same launchdarkly-server-sdk-*.gem glob for gem push, so this should be consistent.
• fetch-depth: 0 was added to the checkout in release-please.yml's publish job. Verify this is still needed now that the create-tag step has been removed — it may be unnecessary overhead.
• No if guard on attestation in release-please.yml: The Attest build provenance step runs unconditionally within the publish job (which is itself gated on release-created == 'true'). The manual workflow correctly gates on !inputs.dry_run. Confirm this asymmetry is acceptable.
• actions/attest@v4 is referenced by major version tag (not pinned SHA), consistent with existing actions/checkout@v4 usage in this repo.
• Orphaned output cleanup: upload-tag-name was removed from release-please.yml outputs since its only consumer (release-provenance job) was removed. release-created is kept since it gates downstream build-ruby-gem, build-jruby-gem, and publish jobs.

Link to Devin session: https://app.devin.ai/sessions/7d5bda4d9dbe4ae0b950b30a50485e60
Requested by: @keelerm84

---

Note

Medium Risk
Moderate risk because it changes the release/publish GitHub Actions flow and provenance generation; a misconfigured subject-path or permissions could break releases or omit attestations.

Overview
Switches release provenance generation from the SLSA reusable workflow to an inline actions/attest@v4 step in both release-please.yml and manual-publish.yml, granting attestations: write and attesting the built gems via subject-path: 'launchdarkly-server-sdk-*.gem'.

Removes the composite publish action’s gem hashing output and deletes workflow wiring (gem-hash outputs and the standalone release-provenance job) that existed only to feed the old SLSA generator; release-please-config.json is reformatted with no functional change.

^{Written by Cursor Bugbot for commit 609b876. This will update automatically on new commits. Configure here.}

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

[cursor]

Missing artifact-metadata: write permission for actions/attest@v4

Medium Severity

Both workflows declare id-token: write and attestations: write for actions/attest@v4, but are missing the artifact-metadata: write permission. Since January 2026, GitHub requires this fine-grained permission for creating artifact storage records, and the contents: write fallback was deprecated in February 2026. Without it, the "Attest build provenance" step will likely fail with a permissions error, resulting in releases without attestation.

Additional Locations (1)

• .github/workflows/manual-publish.yml#L24-L28