Here we make the following major changes:
* Centralize CRT builder logic into a script utility so that we can share the
logic for building artifacts in CI or locally.
* Simplify the build workflow by calling a reusable workflow many times
instead of repeating the contents.
* Create a workflow that validates whether or not the build workflow and all
child workflows have succeeded to allow for merge protection.
Motivation
* We need branch requirements for the build workflow and all subsequent
integration tests (QT-353)
* We need to ensure that the Enos local builder works (QT-558)
* Debugging build failures can be difficult because one has to hand craft the
steps to recreate the build
* Merge conflicts between Vault OSS and Vault ENT build workflows are quite
painful. As the build workflow must be the same file and name we'll reduce
what is contained in each that is unique. Implementations of building
will be unique per edition so we don't have to worry about conflict
resolution.
* Since we're going to be touching the build workflow to do the first two
items we might as well try and improve those other issues at the same time
to reduce the overhead of backports and conflicts.
Considerations
* Build logic for Vault OSS and Vault ENT differs
* The Enos local builder was duplicating a lot of what we did in the CRT build
workflow
* Version and other artifact metadata has been an issue before. Debugging it
has been tedious and error prone.
* The build workflow is full of brittle copy and paste that is hard to
understand, especially for all of the release editions in Vault Enterprise
* Branch check requirements for workflows are incredibly painful to use for
workflows that are dynamic or change often. The required workflows have to be
configured in Github settings by administrators. They would also prevent us
from having simple docs PRs since required integration workflows always have
to run to satisfy branch requirements.
* Doormat credentials requirements that are coming will require us to modify
which event types trigger workflows. This changes those ahead of time since
we're doing so much to build workflow. The only noticeable impact will be
that the build workflow no longer runs on pushes to non-main or release
branches. In order to test other branches it requires a workflow_dispatch
from the Actions tab or a pull request.
Solutions
* Centralize the logic that determines build metadata and creates releasable
Vault artifacts. Instead of cargo-culting logic multiple times in the build
workflow and the Enos local modules, we now have a crt-builder script which
determines build metadata and also handles building the UI, Vault, and the
package bundle. There are make targets for all of the available sub-commands.
Now what we use in the pipeline is the same thing as the local builder, and
it can be executed locally by developers. The crt-builder script works in OSS
and Enterprise so we will never have to deal with them being divergent or with
special casing things in the build workflow.
* Refactor the bulk of the Vault building into a reusable workflow that we can
call multiple times. This allows us to define Vault builds in a much simpler
manner and makes resolving merge conflicts much easier.
* Rather than trying to maintain a list and manually configure the branch check
requirements for build, we'll trigger a single workflow that uses the github
event system to determine if the build workflow (all of the sub-workflows
included) have passed. We'll then create branch restrictions on that single
workflow down the line.
Signed-off-by: Ryan Cragun me@ryan.ec
* [CI-only] Update RedHat registry tag
There are a few changes being made to RedHat's registry on October 20, 2022 that affect the way images need to be tagged prior to being pushed to the registry. This PR changes the tag to conform to the new standard.
We have other work queued up in crt-workflows-common and actions-docker-build to support the other required changes.
This PR should be merged to `main` and all release branches on or after October 20, 2022, and MUST be merged before your next production release. Otherwise, the automation to push to the RedHat registry will not work.
----
A detailed list of changes shared from RedHat (as an FYI):
The following changes will occur for container certification projects that leverage the Red Hat hosted registry [[registry.connect.redhat.com](http://registry.connect.redhat.com/)] for image distribution:
- All currently published images are migrating to a NEW, Red Hat hosted quay registry. Partners do not have to do anything for this migration, and this will not impact customers. The registry will still utilize [registry.connect.redhat.com](http://registry.connect.redhat.com/) as the registry URL.
- The registry URL currently used to push, tag, and certify images, as well as the registry login key, will change. You can see these changes under the “Images” tab of the container certification project. You will now see a [quay.io](http://quay.io/) address and will no longer see [scan.connect.redhat.com](http://scan.connect.redhat.com/).
- Partners will have the opportunity to auto-publish images by selecting “Auto-publish” in the Settings tab of your certification project. This will automatically publish images that pass all certification tests.
- For new container image projects, partners will have the option to host within their own chosen image registry while using [registry.connect.redhat.com](http://registry.connect.redhat.com/) as a proxy address. This means the end user can authenticate to the Red Hat registry to pull a partner image without having to provide additional authentication to the partner’s registry.
* docker: update redhat_tag
Co-authored-by: Sam Salisbury <samsalisbury@gmail.com>
Disable the fail-fast feature for the matrix strategy. This prevents a
single failure to cascade to all jobs in the matrix. This prevents cases
where other jobs fail before they're able to clean up resources.
Signed-off-by: Ryan Cragun <me@ryan.ec>
Add our initial Enos integration tests to Vault. The Enos scenario
workflow will automatically be run on branches that are created from the
`hashicorp/vault` repository. See the README.md in ./enos a full description
of how to compose and execute scenarios locally.
* Simplify the metadata build workflow jobs
* Automatically determine the Go version from go.mod
* Add formatting check for Enos integration scenarios
* Add Enos smoke and upgrade integration scenarios
* Add Consul backend matrix support
* Add Ubuntu and RHEL distro support
* Add Vault edition support
* Add Vault architecture support
* Add Vault builder support
* Add Vault Shamir and awskms auto-unseal support
* Add Raft storage support
* Add Raft auto-join voter verification
* Add Vault version verification
* Add Vault seal verification
* Add in-place upgrade support for all variants
* Add four scenario variants to CI. These test a maximal distribution of
the aforementioned variants with the `linux/amd64` Vault install
bundle.
Signed-off-by: Ryan Cragun <me@ryan.ec>
Co-authored-by: Rebecca Willett <rwillett@hashicorp.com>
Co-authored-by: Jaymala <jaymalasinha@gmail.com>
If we don't guard against pull_request being null, we do a lot of extra
checkout and path filtering, and it ends up putting everything in the UI
board.
I tested this in another repo, and it seems to behave correctly.
Add Open Source project workflow
This will help us triage open source issues into our various internal
project boards.
I tested this on a separate repo, and it seems to work.
Update Go to 1.18
From 1.17.12
1.18.5 was just released, but not all packages have been updated, so I
went with 1.18.4
Co-authored-by: Steven Clark <steven.clark@hashicorp.com>
This is from https://github.com/hashicorp/backport-assistant/pull/40, so that we backport only the merge commit instead of the individual PR commits. This requires that the PR have been merged using the squash commit strategy, which is our policy. (#15571)
* 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>
* add BuildDate to version base
* populate BuildDate with ldflags
* include BuildDate in FullVersionNumber
* add BuildDate to seal-status and associated status cmd
* extend core/versions entries to include BuildDate
* include BuildDate in version-history API and CLI
* fix version history tests
* fix sys status tests
* fix TestStatusFormat
* remove extraneous LD_FLAGS from build.sh
* add BuildDate to build.bat
* fix TestSysUnseal_Reset
* attempt to add build-date to release builds
* add branch to github build workflow
* add get-build-date to build-* job needs
* fix release build command vars
* add missing quote in release build command
* Revert "add branch to github build workflow"
This reverts commit b835699ecb7c2c632757fa5fe64b3d5f60d2a886.
* add changelog entry
Use the latest version of the actions-packaging-linux@v1 to ensure that
.deb and .rpm artifacts are generated with release.
Signed-off-by: Ryan Cragun <me@ryan.ec>
* achieve parity with ent in core.go
* add VAULT_DISABLE_LOCAL_AUTH_MOUNT_ENTITIES
* parity in build.yml with ent but without adding the +ent
* pass base version to ldflags
Co-authored-by: Kyle Penfound <kpenfound11@gmail.com>
* Make backport assistant work with ENT backport tags
I want the regexp to include word characters and the plus sign on
enterprise. I'm confused about the levels of escaping required, because
this is a shell env var that gets passed to a go program as a regular
expression. I didn't escape the square brackets because the parens
weren't escaped. I matched what was done previously with the '.'s for
the '+' because I also want that literal, but it was unclear from
playing around with https://regex101.com/ and go regexps whether the
extra backslashes were required for the '+' char.
* Update .github/workflows/backport.yml
Co-authored-by: Nick Cabatoff <ncabatoff@hashicorp.com>
Co-authored-by: Nick Cabatoff <ncabatoff@hashicorp.com>
This way we can have an OSS action, and an ENT action. We'll be able to
keep the backport-assistant workflows the same on OSS and ENT for normal
PRs, and have a separate labeling system on OSS for docs backports.
We should delete the backport-docs.yml file on ENT.
* feat: add `backport.yml`
* feat: check releases over labels for latest
* chore: Do not automerge for non `stable-website`
* chore: Do not automerge to not `stable-website`
* Update .github/workflows/backport.yml
Co-authored-by: Meggie <meggie@hashicorp.com>
Co-authored-by: Meggie <meggie@hashicorp.com>
Mike Baum