Automation Improvements

[sophiewigmore]

Background

With the large scale of the projects, it can be difficult to find time to manage releases and PRs that come in, in a timely manner. This issue summarizes some ideas that would decrease maintainer toil around our every day release process.

Auto-release buildpacks

Since we don't have complicated versioning logic in the buildpacks, I think we should automatically publish the drafted implementation buildpack releases every week, on a schedule. Then, the main work needed by maintainers would be releasing the language family buildpacks, which is relatively straightforward and quick in comparison to releasing the implementation buildpacks

• add workflow/action to auto-release buildpacks #929

Auto-label all scripts/workflow change PRs

We auto-label some of our automated PRs, but not all. When this functionality was introduced in #360, we erred on the conservative side. Since then, I haven't observed any reason not to add the rest of our scripts/workflows to our patch file list, and let those PRs get auto-merged.

Improve auto-approval functionality

This is a useful workflow to have, but it often fails with unhelpful errors. We should look into streamlining this workflow, and see if we can increase its success rate

Keep Golang up-to-date automatically

This is a follow on from https://github.com/orgs/paketo-buildpacks/discussions/283, which I believe would be helpful

• Add workflow to update go mod version. #928

Questions/Other ideas?

If you have an argument against any of these proposals, or you'd like to add anything, feel free to comment.

[ForestEckhardt]

Auto-release buildpacks

YES! YES! YES!

Auto-label all scripts/workflow change PRs

I think that this makes sense I would save a lot of extra work. I would almost want this change to not trigger any bump for release as it is just tooling but sometimes a tooling update patches other functionality so I think that making it all patches would be great.

Improve auto-approval functionality

Do we have any working theories on how to improve this? Do you know if there is an easy way to enable github native auto merge on PRs?

Keep Golang up-to-date automatically

Was there a resolution to the discussion you linked? I think that setting stable would be my most preferred move but I am unclear on any drawbacks.

[sophiewigmore]

@ForestEckhardt RE: auto-update Golang - not sure if there was a formal resolution. @dmikusa said he was going to get this done in Java, but I'm not sure how he planned to do this. My plan was to (A) make sure we're using go-version: stable in ALL of our workflows, and then (B) add a workflow to bump the Go version in the go.mod

[ForestEckhardt]

add a workflow to bump the Go version in the go.mod

It may be worth it for us to do a bit of investigation and see if this is actually necessary or if it is superficial. I always though the version in the go.mod was the minimum compatible version.

[sophiewigmore]

@ForestEckhardt
RE: Improve auto-approval functionality question - this is a bit of a cheeky proposal, as @robdimsdale had already investigated this in a similar workflow in another project. From that investigation, it seems like the main issue is the homemade download-artifact action. Switching to the official upstream upload/download action should help a bit, plus adding some debugging logs

[robdimsdale]

Auto-release buildpacks

I see no reason not to do this. I think the question should be whether we want to do this on a cadence or just whenever a release is ready. I see pros and cons to both.

Auto-label all scripts/workflow change PRs

I think that this makes sense I would save a lot of extra work. I would almost want this change to not trigger any bump for release as it is just tooling but sometimes a tooling update patches other functionality so I think that making it all patches would be great.

Yeah, I've been thinking about the idea of auto-labeling semver:no-op label, which wouldn't even result in a new draft release, but then we run into edge-cases where we make a change like go-version: 'stable' in the "create release" pipeline which does potentially imply a patch release. Also we would need a new mechanism for creating draft releases on a reliable cadence because currently we are able to rely on the bumps to CI resulting in new patch releases.

If there's a cognitively simple way to thread this needle I'd be all for it. I just haven't found a mechanism that is simpler and not less reliable than we currently have.

Improve auto-approval functionality

Do we have any working theories on how to improve this? Do you know if there is an easy way to enable github native auto merge on PRs?

As @sophiewigmore says - I found that switching from our custom-written action to the github marketplace action improved reliability of downloading artifacts substantially.

I don't think GitHub has any way to auto-approve PRs - even for built-in systems like dependabot. As far as I can tell, we're stuck with doing this ourselves.

Go version

@ForestEckhardt RE: auto-update Golang - not sure if there was a formal resolution. @dmikusa said he was going to get this done in Java, but I'm not sure how he planned to do this. My plan was to (A) make sure we're using go-version: stable in ALL of our workflows, and then (B) add a workflow to bump the Go version in the go.mod

I agree, with the clarification that we would bump the toolchain version, not the go version in go.mod.

[sophiewigmore]

@robdimsdale #928 submit for the Go version item