mirror of
https://github.com/hashicorp/vault.git
synced 2025-08-22 15:11:07 +02:00
3 Commits
Author | SHA1 | Message | Date | |
---|---|---|---|---|
|
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> |
||
|
3e9f84e666
|
[VAULT-36202] pipeline(releases): add releases list active-versions command (#30658)
While working on VAULT-34829 it became apparent that if our new backporter could know which branches are active and which CE counterparts are active then we could completely omit the need for `ce` backport labels and instead automatically backport to corresponding CE branches that are active. To facilitate that we can re-use our `.release/versions.hcl` file as it is the current source of truth for our present backport assistant workflow. Here we add a new `pipeline releases list versions` command that is capable of decoding that file and optionally displaying it. It will be used in the next PR that fully implements VAULT-34829. As part of this work we refactors `pipeline releases` to include a new `list` sub-command and moved both `list-active-versions` and `versions` to it. We also include a few small fixes that were noticed: - `.release/verions.hcl` was not up-to-date - Our cached dynamic config was not getting recreated when the pipeline tool changed. That has been fixed so now dynamic config should always get recreated when the pipeline binary changes - We now initialize a git client when using the `github` sub-command. This will be used in more forthcoming work - Update our changed file detection to resolve some incorrect groupings - Add some additional changed file helpers that we be used in forthcoming work Signed-off-by: Ryan Cragun <me@ryan.ec> |
||
|
ce5885279b
|
VAULT-31181: Add pipeline tool to Vault (#28536)
As the Vault pipeline and release processes evolve over time, so too must the tooling that drives them. Historically we've utilized a combination of CI features and shell scripts that are wrapped into make targets to drive our CI. While this approach has worked, it requires careful consideration of what features to use (bash in CI almost never matches bash in developer machines, etc.) and often requires a deep understanding of several CLI tools (jq, etc). `make` itself also has limitations in user experience, e.g. passing flags. As we're all in on Github Actions as our pipeline coordinator, continuing to utilize and build CLI tools to perform our pipeline tasks makes sense. This PR adds a new CLI tool called `pipeline` which we can use to build new isolated tasks that we can string together in Github Actions. We intend to use this utility as the interface for future release automation work, see VAULT-27514. For the first task in this new `pipeline` tool, I've chosen to build two small sub-commands: * `pipeline releases list-versions` - Allows us to list Vault versions between a range. The range is configurable either by setting `--upper` and/or `--lower` bounds, or by using the `--nminus` to set the N-X to go back from the current branches version. As CE and ENT do not have version parity we also consider the `--edition`, as well as none-to-many `--skip` flags to exclude specific versions. * `pipeline generate enos-dynamic-config` - Which creates dynamic enos configuration based on the branch and the current list of release versions. It takes largely the same flags as the `release list-versions` command, however it also expects a `--dir` for the enos directory and a `--file` where the dynamic configuration will be written. This allows us to dynamically update and feed the latest versions into our sampling algorithm to get coverage over all supported prior versions. We then integrate these new tools into the pipeline itself and cache the dynamic config on a weekly basis. We also cache the pipeline tool itself as it will likely become a repository for pipeline specific tooling. The caching strategy for the `pipeline` tool itself will make most workflows that require it super fast. Signed-off-by: Ryan Cragun <me@ryan.ec> |