search

akuity / kargo-render

Tool and library for managing rendered, environment-specific branches
Apache License 2.0
46 stars 17 forks source link

discussion: is there some better way to manage prs? #62

Closed krancour closed 1 year ago

krancour commented 1 year ago

Related to #37?

Dogfooding Bookkeeper in akuityio/akuity-platform-deploy, we observe a common pattern:

There may be a series of attempts to get some setting right in the test env, and this results in a number of different PRs being opened against the prod branch. All but the last can and should be closed without being merged.

It would be great to cut down on this sort of noise.

This issue is just a place for us to discuss some ideas.

krancour commented 1 year ago

The ideas related to #37 will help a little here, although they won't solve the problem entirely.

The full solution to the problem probably comes from validating branches before promoting. That will be K8sTA's job.

krancour commented 1 year ago

The full solution to the problem probably comes from validating branches before promoting. That will be K8sTA's job.

In yesterday's discussion, I think we mostly agreed on this, however, we also established that it's very important for adoption that we (and thus others) be able to recreate their existing workflows pretty easily.

Pre-bookkeeper, we were aggregating all changes for a given target branch in a predictably named branch that was continuously amended. We'd like Bookkeeper to be able to accommodate that.

I'm not convinced we will still want things to work that way in a future state wherein something like K8sTA affords us the luxury of validating branches / environments before promoting to the next logical environment / branch, so I will make this configurable. We'll use predictable branch names by default to cut down on the total numbers of PRs, but we'll leave an option to open a PR per rendering request.

krancour commented 1 year ago

Regrettably, the GitHub API doesn't seem to have a way to search for open PRs by branch, so to use predictable branch names for PRs to a given environment-specific branch, what we need to do is push to the predictable branch name then unconditionally attempt to open a PR. If the attempt to open the PR fails, we need to examine the error message to determine if the reason is that there is already an open PR associated with that branch. Errors of that nature can be disregarded.

This is the same strategy employed by the peter-evans/create-pull-request GitHub Action, with which we are already familiar:

https://github.com/peter-evans/create-pull-request/blob/main/src/github-helper.ts#L52-L75