Open sophiewigmore opened 4 months ago
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.
@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
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.
@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
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.
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.
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.
@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
.
@robdimsdale https://github.com/paketo-buildpacks/github-config/pull/928 submit for the Go version item
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
Auto-label all scripts/workflow change PRs
We auto-label some of our automated PRs, but not all. When this functionality was introduced in https://github.com/paketo-buildpacks/github-config/pull/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
Questions/Other ideas?
If you have an argument against any of these proposals, or you'd like to add anything, feel free to comment.