* actions: pin to latest actions
- actions/checkout@9c091bb21b => v7.0.0
Adds a guardrail to prevent accidentally checking out fork pull
request code in privileged GitHub Actions contexts
(pull_request_target and PR-triggered workflow_run), with an
explicit opt-in escape hatch for advanced workflows.
- pnpm/action-setup@0ebf47130e => v6.0.9
Update pnpm to v11.7.0
- Add .github/actions/build-ui to ui changed files group
- Add .github/actions/build-ui to ui/frontend CODEOWNERS
Signed-off-by: Ryan Cragun <me@ryan.ec>
Co-authored-by: Ryan Cragun <me@ryan.ec>
Since moving to the standard runner labels we've seen a significant
decrease in job wait time but the smaller runners that we can get for
various jobs are too unreliable and we're seeing many disconnects.
Instead, increase the baseline runner size for build and test
workflows to large. This will likely require waiting longer but that
is almost certainly better than a runner disconnect and retry.
Signed-off-by: Ryan Cragun <me@ryan.ec>
* updates build-ui action to run setup-node before pnpm/action-setup
* fixes issue with empty pnpm store path
* executes pnpm from directory since it isn't on the path
* updates to hardcoded pnpm store path
* one more attempt at getting pnpm store path
* reverts to hardcoded path
* fixes bad revert
* updates pnpm store cache key and adds cache hit guard
* removes restore-key
Co-authored-by: Jordan Reimer <zofskeez@gmail.com>
* actions: expressions in composite action defaults don't work 🫢 (#15023)
Signed-off-by: Ryan Cragun <me@ryan.ec>
Co-authored-by: Ryan Cragun <me@ryan.ec>
Backport community files that changed as part the enterprise only zap scenarios. This mostly includes fixes to scenario execution, retries, and blackbox SDK tests that were broken.
Signed-off-by: Ryan Cragun <me@ryan.ec>
Co-authored-by: Ryan Cragun <me@ryan.ec>
We've been seeing Github throw 500s a lot today when downloading nfpm.
My assumption is that this is due to throttling while Github works to
resolve their platform reliability. Instead of relying on the default
workflow token which has a lower priority than users, use the service
user token when calling the action that downloads nfpm to package Vault.
Signed-off-by: Ryan Cragun <me@ryan.ec>
Co-authored-by: Ryan Cragun <me@ryan.ec>
Use standard runner labels for all workflows. This will allow us to pull
from the hot pools for most jobs and on-demand when more are needed.
This does elimate our cost optimization but latest on-demand runners
have taken so long to provision as to be unbearable.
Signed-off-by: Ryan Cragun <me@ryan.ec>
Co-authored-by: Ryan Cragun <me@ryan.ec>
* [VAULT-43364] pipeline: add template generation support
Add a new `template` to the `pipeline generate` command tree. It allows
rendering Go text templates with pipeline requests available via context
functions. The new system is now product agnostic and can be used to
generate any template we wish. This will supersede the enos specific
configuration command.
We also add support for multiple cadences when fetching the list of
release versions. Previously it was assumed that we followed a minor
version bump cadence when fetching versions with an n-minus style lower
bound. Now we can specify the major or minor cadence. To support a
migration from one cadence to another you can also specify an prior
cadence and the version at which the transition happened. This allows
the n-3 reverse traversal to drop into the prior cadence if/when
necessary.
**Template Rendering System**
- New `pipeline generate template` command renders Go templates with
pipeline data access
- Supports stdin/stdout or file-based input/output
- Templates access version data via function calls rather than
pre-populated context
**Version Cadence Support**
- Added `VersionCadence` type with `minor` and `major` release cadence
tracking
- Supports cadence transitions (e.g., minor→major) with
`TransitionVersion` and `PriorCadence` fields
- Calculates version ranges respecting different release cadences
**Template Functions**
- `VersionsNMinus` / `VersionsBounded` - List versions with explicit
cadence parameter
- `VersionsNMinusTransition` / `VersionsBoundedTransition` - Handle
cadence transitions
- `ParseVersion`, `CompareVersions`, `FilterVersions` - Version
utilities
- All functions require cadence to be explicitly specified
**CLI Integration**
- `--version` and `--edition` flags expose current version/edition to
templates
- Templates reference these via `.Version` and `.Edition` context fields
**Enos Migration**
- Converted `enos-dynamic-config.hcl` to template-based generation
- Uses `VersionsNMinusTransition` to handle Vault's minor→major cadence
shift at 1.21.5
Signed-off-by: Ryan Cragun <me@ryan.ec>
Co-authored-by: Ryan Cragun <me@ryan.ec>
- actions/cache => v5.0.4
Dep updates
- actions/download-artifact => v8.0.1
Support for CJK characters
- dorny/paths-filter => v4.0.1
Node 24, support for merge queues
- hashicorp/action-setup-enos => v1.52
Security release for downstream vuln
- pnpm/action-setup => v5.0.0
Node 24, support for native caching
- slackapi/slack-github-action => v3.0.1
Node 24, lots of internal dep updates, ability to run Slack commands
Signed-off-by: Ryan Cragun <me@ryan.ec>
Co-authored-by: Ryan Cragun <me@ryan.ec>
- docker/setup-buildx-action v3.12.0 => v4.0.0
Node 24 upgrade, switch to ESM, some deprecated inputs have been
removed.
- docker/build-push-action v6.19.2 => v7.0.0
Node 24 upgrade, switch to ESM, some deprecated envs have been
removed.
- actions/setup-node v6.2.0 => v6.3.0
Bug fixes, internal dep updates, support for parsing `devEngines`.
- action-setup-enos v1.50 => v1.51
Use enos 0.0.36
Signed-off-by: Ryan Cragun <me@ryan.ec>
Co-authored-by: Ryan Cragun <me@ryan.ec>
* rework UI CI workflow to partition JS tests (#11967)
* add setup-pnpm action
* remove reading vault keys from vault server output
* update ci workflow to build app and go binary first, then run tests in partitions
* fix errant tests
* address PR feedback
* Apply suggestions from code review
Co-authored-by: Ryan Cragun <me@ryan.ec>
* more feedback changes
* restore test-helper.js
* restore auth test helpers
* check in ui/tests/helpers/vault-keys.js
* use v7 of download-artifact action
* make test-ui reusable workflow
* add status job
---------
Co-authored-by: Ryan Cragun <me@ryan.ec>
* update new UI tests to run CE tests on the CE branch (#12537)
---------
Co-authored-by: Matthew Irish <39469+meirish@users.noreply.github.com>
Co-authored-by: Ryan Cragun <me@ryan.ec>
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>
* adding ibm tests for ent files
* adding debug commands
* adding code changes
* adding reload tests
* remove settings.json
* remove ryboe q
* changing isHashicorpLicense to isIBMLicense and moving DiagnoseCheckLicenseGeneration to core_util_common.go
* fix test
* reverting non-license related tests
* reverting non-license related tests
* removing hashicorp license test
* modify reload server_ent_test.go
* change ibm-license paths
* adding census reload server test
* moving LicensingEntitlementSelectionConfig to core_util_common.go
* add EntReloadLicenseAndConfig to stubs
* fix operator diagnose bug
* move bug fix into ce and ent files
* add more ibm test cases
* Update command/command_testonly/server_testonly_ent_test.go
* address comments
* make fmt
---------
Co-authored-by: akshya96 <87045294+akshya96@users.noreply.github.com>
Co-authored-by: Jenny Deng <jenny.deng@hashicorp.com>
Update to the latest actions. The primary motivation here is to get the
latest action-setup-enos.
- actions/cache => v5.0.3: security patches
- actions/checkout => v6.0.2: small fixes to git user-agent and tag
fetching
- hashicorp/action-setup-enos => v1.50: security patches
Signed-off-by: Ryan Cragun <me@ryan.ec>
Co-authored-by: Ryan Cragun <me@ryan.ec>
- actions/checkout -> v6.0.2: some minor changes around setting the
ACTIONS_ORCHESTRATION_ID and some fixes to `fetch-tags`.
- actions/setup-python -> v6.2.0: Node 24 compat
Signed-off-by: Ryan Cragun <me@ryan.ec>
Co-authored-by: Ryan Cragun <me@ryan.ec>
- actions/cache -> v5.0.2: A bugfix around not retrying cache entries on
429s.
- actions/setup-go -> v6.2.0: NodeJS bump and internal actions/cache
bump. We don't use the caching in setup-go so this ought to have no
impact for us.
- actions/setup-node -> v6.2.0: internal bump of actions/cache.
- pnpm/action-setup -> v4.2.0: Adds support for .npmrc file.
Signed-off-by: Ryan Cragun <me@ryan.ec>
Co-authored-by: Ryan Cragun <me@ryan.ec>
This change does a few things that might not be obvious:
- We stop requesting the previous runner image. This will result in us
using Docker 29 instead of 28. With this comes changes in our
container build system, most notably that container images are now
exported as OCI images. Every container runtime that we support also
supports OCI images so this ought to have no meaningful impact to
downstream users. One noticeable change is that the image layers are
now compressed so the final image size on disk will be considerably
smaller than before.
- Upgrade `hashicorp/action-setup-enos` to the latest version. This is not
strictly required for this change but as we just released a new version of
the CLI it makes sense to update it here. We should also note that recently
we released a new version of `terraform-provider-enos` which contains
necessary for this change as our docker and kind resources needed to be
updated handle OCI and Docker exported images. Previously they relied on
files that existed only in Docker images.
Signed-off-by: Ryan Cragun <me@ryan.ec>
Co-authored-by: Ryan Cragun <me@ryan.ec>
One feature of ondemand self-hosted runners is that we don't contend
with other repositories for self-hosted runners. The penalty for using
ondemand is that there are no hot runner pools, so provisioning time
is usually around 30 second but in worst can hit the two minutes mark.
These numbers rely on immediately capacity in the default region
(us-west-2). Every once in a while we see runner provisioning times for
ondemand CI runners go into the tens of minutes, presumably due to
capacity issues. Instead of waiting around for a runner that will
fulfill our single instance type, we'll add a few fallback types we can
attempt if we hit a capacity snag on our preferred machine.
Signed-off-by: Ryan Cragun <me@ryan.ec>
Co-authored-by: Ryan Cragun <me@ryan.ec>
* install sqlc before building vcm
* make a meaningless change to trigger CI
* turn off the go.work file
* remove test comment
Co-authored-by: Josh Black <raskchanky@gmail.com>
* 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>
* actions(install-tools): include os and arch in cache key
When caching and/or restoring our tools we should include the os and
arch in the key to ensure that we don't accidentally download the wrong
tools on different runners.
We also update the nightlies to specifically cache arm64 before running
the tests.
* actionlint: add arm self-hosted runner keys
Signed-off-by: Ryan Cragun <me@ryan.ec>
Co-authored-by: Ryan Cragun <me@ryan.ec>
* [VAULT-39671] tools: use github cache for external tools
We currently have some ~13 tools that we need available both locally for
development and in CI for building, linting, and formatting, and testing Vault.
Each branch that we maintain often uses the same set of tools but often pinned
to different versions.
For development, we have a `make tools` target that will execute the
`tools/tool.sh` installation script for the various tools at the correct pin.
This works well enough but is cumbersome if you’re working across many branches
that have divergent versions.
For CI the problem is speed and repetition. For each build job (~10) and Go test
job (16-52) we have to install most of the same tools for each job. As we have
extremely limited Github Actions cache we can’t afford to cache the entire vault
go build cache, so if we were to build them from source each time we incur a
penalty of downloading all of the modules and building each tool from source.
This yields about an extra 2 minutes per job to install all of the tools. We’ve
worked around this problem by writing composite actions that download pre-built
binaries of the same tools instead of building them from source. That usually
takes a few seconds. The downside of that approach is rate limiting, which
Github has become much more aggressive in enforcing.
That leads us to where we are before this work:
- For builds in the compatibility docker container: the tools are built from
source and cached as separate builder image layer. (usually fast as we get
cache hits, slow on cache misses)
- For builds that compile directly on the runner: the tools are installed on
each job runner by composite github actions (fast, uses API requests, prone
to throttling)
- For tests, they use the same composite actions to install the tools on each
job. (fast, uses API requests, prone to throttling)
This also leads to inconsistencies since there are two sources of truth: the
composite actions have their own version pin outside of those in `tools.sh`.
This has led to drift.
We previously tried to save some API requests and move all builds into
the container. That almost works but docker's build conatiner had a hard
time with some esoteric builds. We could special case it but it's a bandaid at
best.
A prior version of this work (VAULT-39654) investigated using `go tool`, but
there were some showstopper issues with that workflow that make it a non-starter
for us. Instead, we’ll attempt to use more actions cache to resolve the
throttling. This will allow us to have a single source of truth for tools, their
pins, and afford us the same speed on cache hits as we had previously without
downloading the tools from github releases thousands of times per day.
We add a new composite github action for installing our tools.
- On cache misses it builds the tools and installs them into a cacheable path.
- On cache hits it restore the cacheable path.
- It adds the tools to the GITHUB_PATH to ensure runner based jobs can find
them.
- For Docker builds it mounts the tools at `/opt/tools/bin` which is
part of the PATH in the container.
- It uses a cache key of the SHA of the tools directory along with the
working directory SHA which is required to deal with actions/cache
issues.
This results in:
- A single source of truth for tools and their pins
- A single cache for tools that can be re-used between all CI and build jobs
- No more Github API calls for tooling. *_Rate limiting will be a thing of
the past._*
Signed-off-by: Ryan Cragun <me@ryan.ec>
Co-authored-by: Ryan Cragun <me@ryan.ec>
Update our pins to the latest version. Essentially all of these are
related actions needing to run on Node 24. Both our self-hosted and the
Github hosted runners that we use are all on a new enough version of
actions/runner that it shouldn't be a problem.
Signed-off-by: Ryan Cragun <me@ryan.ec>
Co-authored-by: Ryan Cragun <me@ryan.ec>
* license: add support for publishing artifacts to IBM PAO (#8366)
Signed-off-by: Ryan Cragun <me@ryan.ec>
Co-authored-by: brian shore <bshore@hashicorp.com>
Co-authored-by: Ethel Evans <ethel.evans@hashicorp.com>
Co-authored-by: Ryan Cragun <me@ryan.ec>
As part of this we also update the pin of gotestsum to 1.12.3 to allow
for building it with Go 1.25.
Signed-off-by: Ryan Cragun <me@ryan.ec>
Co-authored-by: Ryan Cragun <me@ryan.ec>
* VAULT-34830: enable the new workflow (#8661)
* pipeline: various fixes for the cutover to the enterprise first workflow (#8686)
Various small fixes that were discovered when doing the cutover to the enterprise first merge workflow:
- The `actions-docker-build` action infers enterprise metadata magically from the repository name. Use a branch that allows configuring the repo name until it's merged upstream.
- Fix some CE-In-Enterprise outputs in our metadata job.
- Pass the recurse depth flag correctly when creating backports
- Set the package name when calling the `build-vault` composite action
- Disallow merging changes into `main` and `release/*` when executing in the `hashicorp/vault` repository. This is a hack until PSS-909 is resolved.
- Use self-hosted runners when testing arm64 CE containers in enterprise.
Signed-off-by: Ryan Cragun <me@ryan.ec>
Conflicts:
.github/workflows/backport-automation-ent.yml
.github/workflows/test-run-enos-scenario-containers.yml
---------
Signed-off-by: Ryan Cragun <me@ryan.ec>
Various small changes and tweaks to our CI/CD workflows to allow for running CE branches in the context of `hashicorp/vault-enterprise`.
Signed-off-by: Ryan Cragun <me@ryan.ec>
Ubuntu 20.04 has reached EOL and is no longer a supported runner host distro. Historically we've relied on it for our CGO builds as it contains an old enough version of glibc that we can retain compatibility with all of our supported distros and build on a single host distro. Rather than requiring a new RHEL 8 builder (or some equivalent), we instead build CGO binaries inside an Ubuntu 20.04 container along with its glibc and various C compilers.
I've separated out system package changes, the Go toolchain install, and external build tools tools install into different container layers so that the builder container used for each branch is maximally cacheable.
On cache misses these changes result in noticeably longer build times for CGO binaries. That is unavoidable with this strategy. Most of the time our builds will get a cache hit on all layers unless they've changed any of the following:
- .build/*
- .go-version
- .github/actions/build-vault
- tools/tools.sh
- Dockerfile
I've tried my best to reduce the cache space used by each layer. Currently our build container takes about 220MB of cache space. About half of that ought to be shared cache between main and release branches. I would expect total new cache used to be in the 500-600MB range, or about 5% of our total space.
Some follow-up idea that we might want to consider:
- Build everything inside the build container and remove the github actions that set up external tools
- Instead of building external tools with `go install`, migrate them into build scripts that install pre-built `linux/amd64` binaries
- Migrate external to `go tool` and use it in the builder container. This requires us to be on 1.24 everywhere so ought not be considered until that is a reality.
Signed-off-by: Ryan Cragun <me@ryan.ec>
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>
* VAULT-36174: pipeline(go): Deal with relative path issues in cache restore
Cache restore have some surprising relative pathing behavior we need
to deal with. Since our Go module cache-path is in $HOME
(/home/runner/go/...) and $HOME can be different depending on our
self-hosted vs Github hosted runners (/home/runner/actions-runner/_work
vs. /home/runner/work) we need to factor in the absolute path of $HOME
when creating our cache key. If we don't then cache restores will be
incompatible on one or the other runner. This is because the tar restore
uses relative paths backwards our our depth doesn't match on both
runners.
We also slightly change our module caches here to only get
`.../mod/cache` instead of the whole `.../mod` directory. Go is able
to unzip the modules in cache faster than it takes a longer download
with the entire mod directory.
This will double our module caches *sigh* but they ought to be smaller
as they only contain the module zips.
See: https://github.com/actions/cache/issues/1127
Signed-off-by: Ryan Cragun <me@ryan.ec>
* use working dir, not home
Signed-off-by: Ryan Cragun <me@ryan.ec>
* fix logic on no-save
Signed-off-by: Ryan Cragun <me@ryan.ec>
* do a module list after download
Signed-off-by: Ryan Cragun <me@ryan.ec>
---------
Signed-off-by: Ryan Cragun <me@ryan.ec>
