Introducing a new approach to testing Vault artifacts before merge
and after merge/notorization/signing. Rather than run a few static
scenarios across the artifacts, we now have the ability to run a
pseudo random sample of scenarios across many different build artifacts.
We've added 20 possible scenarios for the AMD64 and ARM64 binary
bundles, which we've broken into five test groups. On any given push to
a pull request branch, we will now choose a random test group and
execute its corresponding scenarios against the resulting build
artifacts. This gives us greater test coverage but lets us split the
verification across many different pull requests.
The post-merge release testing pipeline behaves in a similar fashion,
however, the artifacts that we use for testing have been notarized and
signed prior to testing. We've also reduce the number of groups so that
we run more scenarios after merge to a release branch.
We intend to take what we've learned building this in Github Actions and
roll it into an easier to use feature that is native to Enos. Until then,
we'll have to manually add scenarios to each matrix file and manually
number the test group. It's important to note that Github requires every
matrix to include at least one vector, so every artifact that is being
tested must include a single scenario in order for all workflows to pass
and thus satisfy branch merge requirements.
* Add support for different artifact types to enos-run
* Add support for different runner type to enos-run
* Add arm64 scenarios to build matrix
* Expand build matrices to include different variants
* Update Consul versions in Enos scenarios and matrices
* Refactor enos-run environment
* Add minimum version filtering support to enos-run. This allows us to
automatically exclude scenarios that require a more recent version of
Vault
* Add maximum version filtering support to enos-run. This allows us to
automatically exclude scenarios that require an older version of
Vault
* Fix Node 12 deprecation warnings
* Rename enos-verify-stable to enos-release-testing-oss
* Convert artifactory matrix into enos-release-testing-oss matrices
* Add all Vault editions to Enos scenario matrices
* Fix verify version with complex Vault edition metadata
* Rename the crt-builder to ci-helper
* Add more version helpers to ci-helper and Makefile
* Update CODEOWNERS for quality team
* Add support for filtering matrices by group and version constraints
* Add support for pseudo random test scenario execution
Signed-off-by: Ryan Cragun <me@ryan.ec>
Pattern matching was [recently added](https://github.com/hashicorp/crt-orchestrator/pull/51) so that teams no longer have to explicitly list every branch that should trigger the CRT pipeline. This simplifies release preparation- anytime a new release branch is created, it will produce releasable artifacts and exercise the full pipeline.
* Copy UBI Dockerfile into Vault
This Dockerfile was modeled off of the existing Alpine Dockerfile (in
this repo) and the external Dockerfile from the docker-vault repo:
> https://github.com/hashicorp/docker-vault/blob/master/ubi/Dockerfile
We also import the UBI-specific docker-entrypoint.sh, as certain
RHEL/Alpine changes (like interpreter) require a separate entry script.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add UBI build to CRT pipeline
Also adds workflow_dispatch to the CRT pipeline, to allow manually
triggering CRT from PRs, when desired.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Update Dockerfile
Co-authored-by: Sam Salisbury <samsalisbury@gmail.com>
* Update Dockerfile
Co-authored-by: Sam Salisbury <samsalisbury@gmail.com>
* Update Dockerfile
Co-authored-by: Sam Salisbury <samsalisbury@gmail.com>
* Update Dockerfile
* Update Dockerfile
* Update build.yml
Allow for both push to arbitrary branch plus workflow dispatch, per Newsletter article.
Co-authored-by: Sam Salisbury <samsalisbury@gmail.com>
👋 This PR adds a `.release/release-metadata.hcl` file to the repo. This contains static metadata that will be processed and sent as part of the payload in RelAPI POST requests, which will be sent when staging and production releases are triggered.
This can be merged now, but will not have any effect until after the RelAPI launch. This will need to be backported to all active release branches, as well. Similar additions are being added across all projects that publish to releases.hashicorp.com.
* adding CRT to main branch
* cleanup
* um i dont know how that got removed but heres the fix
* add vault.service
Co-authored-by: Kyle Penfound <kpenfound11@gmail.com>
Hamid Ghaf