Use OctoSTS for raising PRs; upgrade actions; run zizmor

[BehnH]

Switch to using OctoSTS with a local trust policy in order to prevent having to close & re-open PRs, since GitHub actions isn't able to trigger it's own workflows. Also upgrade & pin actions versions, then run Zizmor against the workflow files for static analysis of actions code.

[kinyoklion]

We'll want to pin all the SHAs, and include a comment of the specific version.

Suggested change

	uses: actions/upload-artifact@v7
	uses: actions/upload-artifact@c6a366c94c3e0affe28c06c8df20a878f24da3cf # 7.0.0

[BehnH]

I hadn't pinned these since we don't enforce pinning actions from GitHub's official actions org. I'm happy to pin absolutely everything though.

[kinyoklion]

We've been pinning basically everything, but if our general guidance is going to not be pinning official actions, then I could see that.

[kinyoklion]

Is there some background information for this change. The go update pattern is replicated between a few repositories, so I would like a better understanding of goals.

This feels like it could also be useful for a problem we have with the flutter repository. Flutter requires releases be from tags, and we create out tags with a CI job, which then cannot run the flutter publish job. In that case we have to use a PAT for publishing, but maybe we could use this approach instead.

[BehnH]

Is there some background information for this change. The go update pattern is replicated between a few repositories, so I would like a better understanding of goals.

Sure, so when GitHub Actions opens a PR, Actions on that PR do not run until the PR is closed & re-opened by a human actor. There is, however, a way to avoid that step - and that is to either use a Personal (or fine-grained) access token (not ideal, they're long-lived) or use a token generated by a GitHub App.

OctoSTS enables creating a short-lived GitHub App token, using permissions defined in a policy file (in this case, .github/launchdarkly/self.bump-go-versions.sts.yaml) which limits the scope of the token. Policies defined in this repo allow the token to execute operations against it - we do have the ability to create globally scoped policies too. I didn't personally realize we replicated this pattern across a few more places, but there's absolutely no reason why we couldn't replicate it there too.

If you look at the this workflow file, you can see how we use OctoSTS to generate a short-lived token which can publish releases.

[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]

Unnecessary workflow-level permission overridden by job-level permissions

Low Severity

The newly added workflow-level permissions block includes issues: write, but the only job (release-please) defines its own permissions block (with just contents: write and pull-requests: write), which completely overrides the workflow-level permissions. The issues: write permission has no effect on any job. Given this PR's goal of tightening security posture via zizmor, adding an unused broad permission at the workflow level is counterproductive — it could mislead future contributors into thinking issues: write is needed, and any new job added without its own permissions block would unexpectedly inherit it.

 

[kinyoklion]

This is likely because we added the job level permissions to main between the opening of this PR and now, so this is redundant now.

I do generally agree that job level permissions are better than workflow level permissions. Especially being as some jobs execute in repo code and other jobs do not.