mirror of
https://github.com/hashicorp/vault.git
synced 2025-08-23 07:31:09 +02:00
2 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Ryan Cragun
|
d595a95c01
|
[VAULT-37096] pipeline(github): add github copy pr command (#31095)
After the merge workflow has been reversed and branches hosted in
`hashicorp/vault` are downstream from community branches hosted in
`hashicorp/vault-enterprise`, most contributions to the source code
will originate in `hashicorp/vault-enterprise` and be backported to
a community branch in hosted in `hashicorp/vault-enterprise`. These
community branches will be considered the primary source of truth and
we'll automatically push changes from them to mirrors hosted in
`hashicorp/vault`.
This workflow ought to yield a massive efficiency boost for HashiCorp
contributors with access to `hashicorp/vault-enterprise`. Before the
workflow would look something like:
- Develop a change in vault-enterprise
- Manually extract relevant changes from your vault-enterprise branch
into a new community vault branch.
- Add any stubs that might be required so as to support any enterprise
only changes.
- Get the community change reviewed. If changes are necessary it often
means changing and testing them on both the enteprise and community
branches.
- Merge the community change
- Wait for it to sync to enterprise
- *Hope you changes have not broken the build*. If they have, fix the
build.
- Update your enterprise branch
- Get the enterprise branch reviewed again
- Merge enterprise change
- Deal with complicated backports.
After the workflow will look like:
- Develop the change on enterprise
- Get the change reviewed
- Address feedback and test on the same branch
- Merge the change
- Automation will extract community changes and create a community
backport PR for you depending on changes files and branch
activeness.
- Automation will create any enterprise backports for you.
- Fix any backport as necessary
- Merge the changes
- The pipeline will automatically push the changes to the community
branch mirror hosted in hashicorp/vault.
No more
- Duplicative reviews
- Risky merges
- Waiting for changes to sync from community to enterprise
- Manual decompistion of changes from enterprise and community
- *Doing the same PR 3 times*
- Dealing with a different backport process depending on which branches
are active or not.
These changes do come at cost however. Since they always originate from
`vault-enterprise` only HashiCorp employees can take advatange of the
workflow. We need to be able to support community contributions that
originate from the mirrors but retain attribution.
That's what this PR is designed to do. The community will be able to
open a pull request as normal and have it reviewed as such, but rather
than merging it into the mirror we'll instead copy the PR and open it
against the corresponding enterprise base branch and have it merged it
from there. The change will automatically get backported to the
community branch if necessary, which eventually makes it back to the
mirror in hashicorp/vault.
To handle our squash merge workflow while retaining the correct
attribution, we'll automatically create merge commits in the copied PR
that include `Co-Authored-By:` trailers for all commit authors on the
original PR.
We also take care to ensure that the HashiCorp maitainers that approve
the PR and/or are assigned to it are also assigned to the copied PR.
This change is only the tooling to enable it. The workflow that drives
it will be implemented in VAULT-34827.
Signed-off-by: Ryan Cragun <me@ryan.ec>
|
||
|
Ryan Cragun
|
c37b3c46b4
|
VAULT-34822: Add pipeline github list changed-files (#30100)
* VAULT-34822: Add `pipeline github list changed-files`
Add a new `github list changed-files` sub-command to `pipeline` command and
integrate it into the pipeline. This replaces our previous
`changed-files.sh` script.
This command works quite a bit differently than the full checkout and
diff based solution we used before. Instead of checking out the base ref
and head ref and comparing a diff, we now provide either a pull request
number or git commit SHA and use the Github REST API to determine the
changed files.
This approach has several benefits:
- Not requiring a local checkout of the repo to get the list of
changed files. This yields a significant perfomance improvement in
`setup` jobs where we typically determine the changed files list.
- The CLI supports both PRs and commit SHAs.
- The implementation is portable and doesn't require any system tools
like `git` or `bash` to be installed.
- A much more advanced system for adding group metadata to the changed
files. These groupings are going to be used heavily in future
pipeline automation work and will be used to make required jobs
smarter.
The theoretical drawbacks:
- It requires a GITHUB_TOKEN and only works for remote branches or
commits in Github. We could eventually add a local diff sub-command
or option to work locally, but that was not required for what we're
trying to achieve here.
While the groupings that I added in this change are quite rudimentary,
the system will allow us to add additional groups with very little
overhead. I tried to make this change more or less a port of the old
system to enable future work. I did include one small change of
behavior, which is that we now build all extended targets if the
`go.mod` or `go.sum` files change. We do this to ensure that dependency
changes don't subtly result in some extended platform breakage.
Signed-off-by: Ryan Cragun <me@ryan.ec>
|