The `pipeline` utility started as collection of small CLI utilities that we found useful for the Vault CI/CD pipeline. Rather than engineering complex bash scripts in YAML blocks, instead, we could build small, reusable, testable actions and integrate the into a single binary. No more copying and pasting loads of bash from YAML, instead we can copy a single command and run the same thing locally that we can in CI.
As we've continued to invest in the utilities capability, it's become clear that other CI pipelines would benefit from the same functionality that we've been building. This change represents the first significant work to make the utility truly generic in a HashiCorp repo that utilizes CRT sense. Once all the Vault specifics have been extracted we hope to move the utility out of the repo and make it available everywhere.
The primary change here is to move our changed file grouping configuration out of the `changed` package entirely. Instead of checkers that are written as Go code, we have created a new configuration file for the `pipeline` utility called `pipeline.hcl` While there are certainly other things that will eventually be configurable here, the only thing we've added support for is `changed_files`, which allows configuring how to match a given changed files path to a group name.
The DSL is fairly simple:
```hcl
changed_files {
// One or more groups can be defined
group "group_name_label" {
// Zero or more ignore blocks can be defined
ignore {
base_dir = []
base_name = []
base_name_prefix = []
contains = []
extension = []
file = []
}
// One or more match blocks can be defined
match {
base_dir = []
base_name = []
base_name_prefix = []
contains = []
extension = []
file = []
}
}
}
```
For example,
```hcl
// Create a changed_files block where we can define our changed files groups
changed_files {
// Group blocks take one label which is the name of the group
group "app" {
// Groups can ignore based on some criteria.
ignore {
// In this instance, we'll ignore any file that begins with
// tools/pipeline. All paths will be relative to the git repository
// root directory. The joinpath() function is here to support paths
// that are agnostic to the operating systems path separator. While
// it's unlikely that you'll need them, several cty stdlib functions
// are available.
base_dir = [joinpath("tools", "pipeline")]
}
// Groups must define at least one match block.
match {
// This will match any file with the .go extension (except for
// those that will be excluded with our ignore directive aboe
extension = [".go"]
}
// Groups can contain more than one match block. If any of the match
// blocks meet their criteria the group will be associated with the
// changed file
match {
base_name = ["go.mod", "go.sum"]
}
// If groups have more than one attribute set, each attribute group
// must match in order for the match.
match {
// Here we only match files that contain "raft_autopilot" in the
// path with the .go extension
extension = [".go"]
contains = ["raft_autopilot"]
}
}
group "autopilot" {
// Ignore blocks have the same attributes as match blocks
match {
// The base directory.
base_dir = [
"changelog",
joinpath("tools", "codechecker"),
]
// The base of the file
base_name = ["README.md"]
// A prefix string match on a files name.
base_name_prefix = ["buf."]
// Any string match in the files full path
contains = [
"-ce",
"_ce",
"-oss",
"_oss",
]
// The file's extension
extension = [
".hcl",
".md",
".sh",
".yaml",
".yml",
]
// An exact file match
file = [
# These exist on CE branches to please Github Actions.
joinpath(".github", "workflows", "build-artifacts-ent.yml"),
joinpath(".github", "workflows", "backport-automation-ent.yml"),
]
}
}
}
```
The default location of the config is `.release/pipeline.hcl`. All of our prior checks have been migrated to the DSL file present in this change.
- We had several commands that used the changed files groups that were built into the library. This change requires us to instead load the configuration from the file and use the user defined groupings.
- Several commands now take some part of that configuration in the request type. When possible we use the version parsed by the root command and verify in the request body rather than attempt to load the configuration.
- We also refactor the loading and parsing of `.release/versions.hcl` in the same manner. Now we automatically parse the file in the default locations relative to the git repo root.
- Our root command now has two new flags `--pipeline-config` and `--versions-config` which allow specifying a default location for each file. Commands which previously accepted flags or args to configure the versions file have been updated to use the global root flags instead. We've also removed the previous implementation that would recursively search backwards from the working directory to find the `versions.hcl` file. Instead we only support loading the file from the default location relative to the Git repo root.
- All instances of changed `pipeline` command invocations have been update to support the new auto-loading of configuration.
- A new configuration sub-command with validation exists to quickly validate a configuration file. `pipeline config validate`
Signed-off-by: Ryan Cragun <me@ryan.ec>
Co-authored-by: Ryan Cragun <me@ryan.ec>
* license: update headers to IBM Corp.
* `make proto`
* update offset because source file changed
Signed-off-by: Ryan Cragun <me@ryan.ec>
Co-authored-by: Ryan Cragun <me@ryan.ec>
* [VAULT-39424] pipeline(close-origin-pr): add support for closing the origin of copied PRs
When we copy a community contributed Pull Request to Enterprise the
source PR is effectively orphaned, leaving the original PR still
opened, the author unsure of what state the copied PR is in, and any
issues associated with it open.
When the copied PR is closed we ought to close the origin PR if it's
still open, and any other issues that might be associated with either
the origin PR or the copied PR.
We can also add comments to both PRs that include links to each other
and the squash commit to make discovery of the work visible to those
with access to both repos. Unfortunately there is no way to know what
the SHA will be when it's synced so we have to rely on the
'Co-Authored-By:' trailers in commit message.
There are some challenges to this:
- The automation should only execute when copied PRs are closed
- How to determine the origin PR from only the copied PR
- How to determine the PR's linked issues (which the v3 REST API does not expose)
We solved them by:
- Requiring the PR HEAD ref to start with `copy/`
- Encoding the origin PR information in the PR HEAD ref.
e.g. `copy/hashicorp/vault/31580/ryan/VAULT-39424-test-ce`
- Using the V4 GraphQL API to determine "closed issue references"
The result is a new `pipeline` CLI command that can close the origin PR,
all of the issues, and write status comments on each PR with links to
everything to establish omnidirectional linking in the Github UI.
```bash
pipeline github close origin-pull-request 9903
```
* fix feedback
---------
Signed-off-by: Ryan Cragun <me@ryan.ec>
Co-authored-by: Ryan Cragun <me@ryan.ec>
When we copy a Pull Request from CE to Ent we already add a status
comment to the origin PR but we don't actually bubble up the information
to the workflow summary. Instead, render the copy PR output as a
markdown table and write it to the step summary.
Signed-off-by: Ryan Cragun <me@ryan.ec>
Co-authored-by: Ryan Cragun <me@ryan.ec>
Add a new `pipeline github sync branches` command that can synchronize
two branches. We'll use this to synchronize the
`hashicorp/vault-enterprise/ce/*` branches with `hashicorp/vault/*`.
As the community repository is effectively a mirror of what is hosted in
Enterprise, a scheduled sync cadence is probably fine. Eventually we'll
hook the workflow and sync into the release pipeline to ensure that
`hashicorp/vault` branches are up-to-date when cutting community
releases.
As part of this I also fixed a few static analysis issues that popped up
when running `golangci-lint` and fixed a few smaller bugs.
Signed-off-by: Ryan Cragun <me@ryan.ec>
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>
