Move secrets to be protected environment secrets - #8865
Merged
Conversation
andrewlock
added
the
area:builds
BenchmarksBenchmark execution time: 2026-07-03 09:59:58 Comparing candidate commit 8507a75 in PR branch Found 0 performance improvements and 1 performance regressions! Performance is the same for 71 metrics, 0 unstable metrics, 63 known flaky benchmarks, 63 flaky benchmarks without significant changes.
|
andrewlock
marked this pull request as ready for review
July 21, 2026 15:44
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Pass the NuGet username into the reusable workflow
This caller now invokes the release workflow without a secrets: block or secrets: inherit, and the hotfix caller does the same, so repository/organization secrets are no longer automatically available to _create_draft_release.yml. That workflow still passes ${{ secrets.NUGET_TRUSTED_PUBLISHING_USERNAME }} to NuGet/login, and its own failure text points maintainers at the Actions secret for that value, so when the username remains there the expression evaluates to empty and draft release creation fails before NuGet publishing. Please keep passing/inheriting this secret or move it into publish-debug-symbols-env as well.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
andrewlock
added a commit
that referenced
this pull request
Aug 13, 2026
## Summary of changes Tightens up the chainguard policies for the version bump PRs ## Reason for change #8863 updated the docker image version bump and the test package version bump workflows to run inside a protected environment. It probably makes sense to tighten up the sts policies around these workflows too. ## Implementation details Add `environment` to the `subject` and `claim_pattern` ## Test coverage Can't test until we merge 🙈 ## Other details Follow up to - #8863 Related to - #8865 I checked with `/dd-octo-sts` and it said: > The changes are correct and make the policies meaningfully more secure.
link04
approved these changes
Aug 13, 2026
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Summary of changes
Reason for change
We're moving
AZURE_DEVOPS_TOKENfrom being a repo secret to a protected environment secret. This does some of the associated cleanup.Implementation details
create_normal_draft_releaseworkflow was trying to access and pass in the variables, but as it wasn't running in anenvironment, this was passing an empty string. However, this didn't break anything, because{{ secrets.AZURE_DEVOPS_TOKEN }}was transparently accessing the environment secret anyway. So we can just stop trying to pass them in now.create-system-test-docker-base-images.ymlneeds to be in the "release" env, because it needs the azure devops token to grab the build results from CI (avoiding rate limits)Additionally, I duplicated the repo-secret
AZURE_DEVOPS_TOKENinto the existingpublish-debug-symbols-envenvironment, so when we merge this, everything should "just work".Finally, we can make the
publish-debug-symbols-env, "protected" so it only runs on release branches.Test coverage
Nope, we can't really test any of this 🙁 Hence why I want to babysit it the first time 😅
Other details
I'd like to change
publish-debug-symbols-envto be calledrelease-env(or something similar), but that means changing a whole bunch ofststoken stuff, across multiple repos, and it doesn't seem worth the hassle 😅