Add workflow to synchronize go mod changes with submodules

[codysoyland]

Summary

This PR attempt to improve the workflow of managing Dependabot updates to this repo. The problem is that when Dependabot updates a dependency in the main module, those updates are not reflected in the "submodule" (https://github.com/sigstore/sigstore-go/tree/main/examples/oci-image-verification) which includes a reference to the main module. That causes the build to fail, and one maintainer must manually run go mod tidy in the submodule and push those changes, and another maintainer must approve and merge them (as the last committer is disallowed from merging a PR). (example)

This PR automatically runs go mod tidy in both modules and commits/pushes them whenever Dependabot creates a new PR.

There is a caveat with this, which is that the actions do not run when the last committer used GITHUB_TOKEN to authenticate to the Git server, which is intentional to avoid accidentally creating recursively invoked workflows. This can be worked around by using a PAT in this workflow to authenticate to the Git server, or maintainers can push an empty commit to trigger the Actions workflows.

If this seems like a good approach to fellow maintainers, I'd recommend we create a PAT for use within this repo and modify this workflow to use it.

This workflow could also be added to sigstore/sigstore for use with the KMS providers (example).

Release Note

Documentation

[kommendorkapten]

Thanks Cody! This looks good.
I think it may even work to just re-run the failing workflows from the UI instead of pushing an empty commit?

[codysoyland]

I think it may even work to just re-run the failing workflows from the UI instead of pushing an empty commit?

I don't think there's a way to trigger the workflows from the UI if they are not run due to the last commit originating from Actions -- they are not actually "failed" workflows, they just aren't created at all. Maybe I'm missing something, but I think it would require an empty commit to trigger the build, unless we add a PAT to a secret and use it to commit the go.mod changes.

@haydentherapper (or maybe @cpanato?), what do you think of incorporating this workflow and using a PAT to authenticate with git? As explained in the description, we need to use a PAT or the actions-generated commit will not trigger actions to run again, therefore the automation would be incomplete. We can create an org-level PAT secret and also use it to keep the kms providers in sigstore/sigstore up to date using the same workflow. Somebody who is org admin would need to create the PAT and upload it as an org-level secret.

[haydentherapper]

I really like this workflow, this is great! This has definitely been a nuisance here and in Sigstore/sigstore.

PATs are a little annoying to keep up to date, but we’ve already got a number that we manage, one more is fine. In the future, we can look at creating a GitHub app to replace PATs.

what are the permissions needed for the PAT?

[haydentherapper]

Should this be an ID? If someone names their account this string, this would run. Not really a big deal though

[codysoyland]

This is the documented way. The actor name is a user name of the entity that triggered the workflow.

[bobcallaway]

I agree with Hayden's question here - having this pinned to an immutable ID feels marginally safer.

[haydentherapper]

What if the modules don’t use the same version of go? Should we search for all go.mod files, then install go and run go mod tidy for each?

[codysoyland]

I hadn't considered that, but I think we'd hit an error in that case, and we'd need to manually sync up the go versions.

[kommendorkapten]

If we create a go.work and workspace, we can define the go version at the top level and use go-version-file: go.work, then rely on go work sync to propagate the version to the sub modules. That could probably be part of this workflow too.

[codysoyland]

PATs are a little annoying to keep up to date, but we’ve already got a number that we manage, one more is fine. In the future, we can look at creating a GitHub app to replace PATs.

Yeah an app is ideal, just requires a little more setup. PATs are indeed annoying.

what are the permissions needed for the PAT?

It can be a fine-grained permission PAT with support to the specific repos we need (sigstore, sigstore-go), with "Contents" set to "Read and write".

[haydentherapper]

@cpanato can you create the PAT?

[haydentherapper]

Coming back to this, I can create the PAT...but with that said, keeping these PATs up to date is a bit annoying as they expire. Is there any way to do this without another PAT?

[codysoyland]

Coming back to this, I can create the PAT...but with that said, keeping these PATs up to date is a bit annoying as they expire. Is there any way to do this without another PAT?

I believe we can do this with a GitHub app.... I can test it on my own org first to make sure and help you set it up if that works!

[haydentherapper]

We had also looked into https://github.com/apps/octo-sts awhile ago which Chainguard made.

[cpanato]

sorry for the delay here

we can create a PAT, but i would vote to use the octo-sts, because we dont need to manage the PAT and that will be valid only for the job execution

[cpanato]

and this looks soo cool!!

[codysoyland]

octo-sts is awesome, I just tried it on a test repo and it works great for this purpose. I'll update the PR

[haydentherapper]

We'll need to install it in the org as well. Should mention this to the TSC before we progress.

[codysoyland]

I updated the workflow to use octo-sts, so if TSC approves, we can proceed to merging this.

[haydentherapper]

@codysoyland Can you file an issue on https://github.com/sigstore/tsc asking for approval?

[codysoyland]

@codysoyland Can you file an issue on https://github.com/sigstore/tsc asking for approval?

sigstore/TSC#51

[bobcallaway]

Suggested change

	cd examples/oci-image-verification; go mod tidy
	cd examples/oci-image-verification && go mod tidy