luxolus/open-vault
2
0
Fork 0
Code Issues 1 Pull requests Releases Activity
open-vault/.github/workflows/ci.yml

417 lines
18 KiB
YAML
Raw Normal View History

Introduce GitHub Actions CI Workflow (#19449) * Migrate subset of CircleCI ci workflow to GitHub Actions Runs test-go and test-go-remote-docker with a static splitting of test packages * [skip actions] add comment to explain the purpose of test-generate-test-package-lists.sh and what to do if it fails * change trigger to push --------- Co-authored-by: Kuba Wieczorek <kuba.wieczorek@hashicorp.com>
2023-03-06 21:57:55 +00:00
name: CI
on:
Add a GHA job running Go tests with race detection enabled to the CI … (#19561) * Add a GHA job running Go tests with race detection enabled to the CI workflow * Incorporate logic from test-go-race into the test-go testing matrix * Make test-go testing matrix job names more meaningful * Fix some a bug in script's logic * Experiment: bump wait time in the failing TestLoginMFASinglePhase test to see if that makes a difference * Lower the wait time in TestLoginMFASinglePhase * Change the wait time in TestLoginMFASinglePhase to 15 * Add more detail to test-go testing matrix job names * Test whether we already have access to larger runners * Run Go tests with enabled data race detection from a separate job than the standard suite of tests * Tweak runner sizes for OSS * Try rebalancing test buckets * Change instance type for larger ENT runners * Undo rebalancing of test buckets as it changed nothing * Change instance type for larger OSS runners * Change the way we generate names for matrix jobs * Consolidate the Go build tags variables, update them to use comma as a separator and fix the if statement in test-go * Fix a typo
2023-03-21 18:13:40 +00:00
pull_request:
Don't run build workflow on draft PRs. (#20443)
2023-05-01 17:52:41 +00:00
# The default types for pull_request are [ opened, synchronize, reopened ].
# This is insufficient for our needs, since we're skipping stuff on PRs in
# draft mode. By adding the ready_for_review type, when a draft pr is marked
# ready, we run everything, including the stuff we'd have skipped up until now.
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
types: [opened, synchronize, reopened, ready_for_review]
Introduce GitHub Actions CI Workflow (#19449) * Migrate subset of CircleCI ci workflow to GitHub Actions Runs test-go and test-go-remote-docker with a static splitting of test packages * [skip actions] add comment to explain the purpose of test-generate-test-package-lists.sh and what to do if it fails * change trigger to push --------- Co-authored-by: Kuba Wieczorek <kuba.wieczorek@hashicorp.com>
2023-03-06 21:57:55 +00:00
push:
Add a GHA job running Go tests with race detection enabled to the CI … (#19561) * Add a GHA job running Go tests with race detection enabled to the CI workflow * Incorporate logic from test-go-race into the test-go testing matrix * Make test-go testing matrix job names more meaningful * Fix some a bug in script's logic * Experiment: bump wait time in the failing TestLoginMFASinglePhase test to see if that makes a difference * Lower the wait time in TestLoginMFASinglePhase * Change the wait time in TestLoginMFASinglePhase to 15 * Add more detail to test-go testing matrix job names * Test whether we already have access to larger runners * Run Go tests with enabled data race detection from a separate job than the standard suite of tests * Tweak runner sizes for OSS * Try rebalancing test buckets * Change instance type for larger ENT runners * Undo rebalancing of test buckets as it changed nothing * Change instance type for larger OSS runners * Change the way we generate names for matrix jobs * Consolidate the Go build tags variables, update them to use comma as a separator and fix the if statement in test-go * Fix a typo
2023-03-21 18:13:40 +00:00
branches:
CI tests should run on release branches as well as main (#20444)
2023-05-01 15:42:03 +00:00
- main
- release/**
add workflow_dispatch trigger to ci.yml workflow (#19979)
2023-04-05 14:03:08 +00:00
workflow_dispatch:
[QT-589] Use the go module cache between CI and build (#21764) (#21790) In order to reliably store Go test times in the Github Actions cache we need to reduce our cache thrashing by not using more than 10gb over all of our caches. This change reduces our cache usage significantly by sharing Go module cache between our Go CI workflows and our build workflows. We lose our per-builder cache which will result in a bit of performance hit, but we'll enable better automatic rebalancing of our CI workflows. Overall we should see a per branch reduction in cache sizes from ~17gb to ~850mb. Some preliminary investigation into this new strategy: Prior build workflow strategy on a cache miss: Download modules: ~20s Build Vault: ~40s Upload cache: ~30s Total: ~1m30s Prior build workflow strategy on a cache hit: Download and decompress modules and build cache: ~12s Build Vault: ~15s Total: ~28s New build workflow strategy on a cache miss: Download modules: ~20 Build Vault: ~40s Upload cache: ~6s Total: ~1m6s New build workflow strategy on a cache hit: Download and decompress modules: ~3s Build Vault: ~40s Total: ~43s Expected time if we used no Go caching: Download modules: ~20 Build Vault: ~40s Total: ~1m Signed-off-by: Ryan Cragun <me@ryan.ec> Co-authored-by: Ryan Cragun <me@ryan.ec>
2023-07-12 19:26:00 +00:00
backport of commit eecae3a827f523a25359068ad6714af8f28c6ced (#21550) (#21556) Co-authored-by: miagilepner <mia.epner@hashicorp.com>
2023-07-04 15:07:05 +00:00
concurrency:
group: ${{ github.head_ref || github.run_id }}-ci
cancel-in-progress: true
[QT-589] Use the go module cache between CI and build (#21764) (#21790) In order to reliably store Go test times in the Github Actions cache we need to reduce our cache thrashing by not using more than 10gb over all of our caches. This change reduces our cache usage significantly by sharing Go module cache between our Go CI workflows and our build workflows. We lose our per-builder cache which will result in a bit of performance hit, but we'll enable better automatic rebalancing of our CI workflows. Overall we should see a per branch reduction in cache sizes from ~17gb to ~850mb. Some preliminary investigation into this new strategy: Prior build workflow strategy on a cache miss: Download modules: ~20s Build Vault: ~40s Upload cache: ~30s Total: ~1m30s Prior build workflow strategy on a cache hit: Download and decompress modules and build cache: ~12s Build Vault: ~15s Total: ~28s New build workflow strategy on a cache miss: Download modules: ~20 Build Vault: ~40s Upload cache: ~6s Total: ~1m6s New build workflow strategy on a cache hit: Download and decompress modules: ~3s Build Vault: ~40s Total: ~43s Expected time if we used no Go caching: Download modules: ~20 Build Vault: ~40s Total: ~1m Signed-off-by: Ryan Cragun <me@ryan.ec> Co-authored-by: Ryan Cragun <me@ryan.ec>
2023-07-12 19:26:00 +00:00
Introduce GitHub Actions CI Workflow (#19449) * Migrate subset of CircleCI ci workflow to GitHub Actions Runs test-go and test-go-remote-docker with a static splitting of test packages * [skip actions] add comment to explain the purpose of test-generate-test-package-lists.sh and what to do if it fails * change trigger to push --------- Co-authored-by: Kuba Wieczorek <kuba.wieczorek@hashicorp.com>
2023-03-06 21:57:55 +00:00
jobs:
setup:
name: Setup
runs-on: ubuntu-latest
outputs:
Add a new category of runners to the CI workflow… (#19807) * Add a new category of runners to the CI workflow; use new, dedicated runners on OSS; adjust runner sizes for jobs Co-authored-by: Marc Boudreau <marc.boudreau@hashicorp.com>
2023-03-30 15:41:40 +00:00
compute-tiny: ${{ steps.setup-outputs.outputs.compute-tiny }}
Add a GHA job running Go tests with race detection enabled to the CI … (#19561) * Add a GHA job running Go tests with race detection enabled to the CI workflow * Incorporate logic from test-go-race into the test-go testing matrix * Make test-go testing matrix job names more meaningful * Fix some a bug in script's logic * Experiment: bump wait time in the failing TestLoginMFASinglePhase test to see if that makes a difference * Lower the wait time in TestLoginMFASinglePhase * Change the wait time in TestLoginMFASinglePhase to 15 * Add more detail to test-go testing matrix job names * Test whether we already have access to larger runners * Run Go tests with enabled data race detection from a separate job than the standard suite of tests * Tweak runner sizes for OSS * Try rebalancing test buckets * Change instance type for larger ENT runners * Undo rebalancing of test buckets as it changed nothing * Change instance type for larger OSS runners * Change the way we generate names for matrix jobs * Consolidate the Go build tags variables, update them to use comma as a separator and fix the if statement in test-go * Fix a typo
2023-03-21 18:13:40 +00:00
compute-standard: ${{ steps.setup-outputs.outputs.compute-standard }}
compute-larger: ${{ steps.setup-outputs.outputs.compute-larger }}
Add larger runners for CI (#19857)
2023-03-30 16:58:32 +00:00
compute-huge: ${{ steps.setup-outputs.outputs.compute-huge }}
Introduce GitHub Actions CI Workflow (#19449) * Migrate subset of CircleCI ci workflow to GitHub Actions Runs test-go and test-go-remote-docker with a static splitting of test packages * [skip actions] add comment to explain the purpose of test-generate-test-package-lists.sh and what to do if it fails * change trigger to push --------- Co-authored-by: Kuba Wieczorek <kuba.wieczorek@hashicorp.com>
2023-03-06 21:57:55 +00:00
enterprise: ${{ steps.setup-outputs.outputs.enterprise }}
[QT-589] Use the go module cache between CI and build (#21764) (#21790) In order to reliably store Go test times in the Github Actions cache we need to reduce our cache thrashing by not using more than 10gb over all of our caches. This change reduces our cache usage significantly by sharing Go module cache between our Go CI workflows and our build workflows. We lose our per-builder cache which will result in a bit of performance hit, but we'll enable better automatic rebalancing of our CI workflows. Overall we should see a per branch reduction in cache sizes from ~17gb to ~850mb. Some preliminary investigation into this new strategy: Prior build workflow strategy on a cache miss: Download modules: ~20s Build Vault: ~40s Upload cache: ~30s Total: ~1m30s Prior build workflow strategy on a cache hit: Download and decompress modules and build cache: ~12s Build Vault: ~15s Total: ~28s New build workflow strategy on a cache miss: Download modules: ~20 Build Vault: ~40s Upload cache: ~6s Total: ~1m6s New build workflow strategy on a cache hit: Download and decompress modules: ~3s Build Vault: ~40s Total: ~43s Expected time if we used no Go caching: Download modules: ~20 Build Vault: ~40s Total: ~1m Signed-off-by: Ryan Cragun <me@ryan.ec> Co-authored-by: Ryan Cragun <me@ryan.ec>
2023-07-12 19:26:00 +00:00
go-tags: ${{ steps.setup-outputs.outputs.go-tags }}
Introduce GitHub Actions CI Workflow (#19449) * Migrate subset of CircleCI ci workflow to GitHub Actions Runs test-go and test-go-remote-docker with a static splitting of test packages * [skip actions] add comment to explain the purpose of test-generate-test-package-lists.sh and what to do if it fails * change trigger to push --------- Co-authored-by: Kuba Wieczorek <kuba.wieczorek@hashicorp.com>
2023-03-06 21:57:55 +00:00
steps:
[QT-589] Use the go module cache between CI and build (#21764) (#21790) In order to reliably store Go test times in the Github Actions cache we need to reduce our cache thrashing by not using more than 10gb over all of our caches. This change reduces our cache usage significantly by sharing Go module cache between our Go CI workflows and our build workflows. We lose our per-builder cache which will result in a bit of performance hit, but we'll enable better automatic rebalancing of our CI workflows. Overall we should see a per branch reduction in cache sizes from ~17gb to ~850mb. Some preliminary investigation into this new strategy: Prior build workflow strategy on a cache miss: Download modules: ~20s Build Vault: ~40s Upload cache: ~30s Total: ~1m30s Prior build workflow strategy on a cache hit: Download and decompress modules and build cache: ~12s Build Vault: ~15s Total: ~28s New build workflow strategy on a cache miss: Download modules: ~20 Build Vault: ~40s Upload cache: ~6s Total: ~1m6s New build workflow strategy on a cache hit: Download and decompress modules: ~3s Build Vault: ~40s Total: ~43s Expected time if we used no Go caching: Download modules: ~20 Build Vault: ~40s Total: ~1m Signed-off-by: Ryan Cragun <me@ryan.ec> Co-authored-by: Ryan Cragun <me@ryan.ec>
2023-07-12 19:26:00 +00:00
- uses: actions/checkout@c85c95e3d7251135ab7dc9ce3241c5835cc595a9 # v3.5.3
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
- id: setup-outputs
name: Setup outputs
run: |
github_repository="${{ github.repository }}"
Introduce GitHub Actions CI Workflow (#19449) * Migrate subset of CircleCI ci workflow to GitHub Actions Runs test-go and test-go-remote-docker with a static splitting of test packages * [skip actions] add comment to explain the purpose of test-generate-test-package-lists.sh and what to do if it fails * change trigger to push --------- Co-authored-by: Kuba Wieczorek <kuba.wieczorek@hashicorp.com>
2023-03-06 21:57:55 +00:00
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
if [ "${github_repository##*/}" == "vault-enterprise" ] ; then
# shellcheck disable=SC2129
echo 'compute-tiny=["self-hosted","ondemand","linux","type=m5.large"]' >> "$GITHUB_OUTPUT"
echo 'compute-standard=["self-hosted","ondemand","linux","type=m5.xlarge"]' >> "$GITHUB_OUTPUT"
echo 'compute-larger=["self-hosted","ondemand","linux","type=m5.2xlarge"]' >> "$GITHUB_OUTPUT"
echo 'compute-huge=["self-hosted","ondemand","linux","type=m5.4xlarge"]' >> "$GITHUB_OUTPUT"
echo 'enterprise=1' >> "$GITHUB_OUTPUT"
[QT-589] Use the go module cache between CI and build (#21764) (#21790) In order to reliably store Go test times in the Github Actions cache we need to reduce our cache thrashing by not using more than 10gb over all of our caches. This change reduces our cache usage significantly by sharing Go module cache between our Go CI workflows and our build workflows. We lose our per-builder cache which will result in a bit of performance hit, but we'll enable better automatic rebalancing of our CI workflows. Overall we should see a per branch reduction in cache sizes from ~17gb to ~850mb. Some preliminary investigation into this new strategy: Prior build workflow strategy on a cache miss: Download modules: ~20s Build Vault: ~40s Upload cache: ~30s Total: ~1m30s Prior build workflow strategy on a cache hit: Download and decompress modules and build cache: ~12s Build Vault: ~15s Total: ~28s New build workflow strategy on a cache miss: Download modules: ~20 Build Vault: ~40s Upload cache: ~6s Total: ~1m6s New build workflow strategy on a cache hit: Download and decompress modules: ~3s Build Vault: ~40s Total: ~43s Expected time if we used no Go caching: Download modules: ~20 Build Vault: ~40s Total: ~1m Signed-off-by: Ryan Cragun <me@ryan.ec> Co-authored-by: Ryan Cragun <me@ryan.ec>
2023-07-12 19:26:00 +00:00
echo 'go-tags=ent,enterprise' >> "$GITHUB_OUTPUT"
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
else
# shellcheck disable=SC2129
echo 'compute-tiny="ubuntu-latest"' >> "$GITHUB_OUTPUT" # 2 cores, 7 GB RAM, 14 GB SSD
echo 'compute-standard="custom-linux-small-vault-latest"' >> "$GITHUB_OUTPUT" # 8 cores, 32 GB RAM, 300 GB SSD
echo 'compute-larger="custom-linux-medium-vault-latest"' >> "$GITHUB_OUTPUT" # 16 cores, 64 GB RAM, 600 GB SSD
echo 'compute-huge="custom-linux-xl-vault-latest"' >> "$GITHUB_OUTPUT" # 32-cores, 128 GB RAM, 1200 GB SSD
echo 'enterprise=' >> "$GITHUB_OUTPUT"
[QT-589] Use the go module cache between CI and build (#21764) (#21790) In order to reliably store Go test times in the Github Actions cache we need to reduce our cache thrashing by not using more than 10gb over all of our caches. This change reduces our cache usage significantly by sharing Go module cache between our Go CI workflows and our build workflows. We lose our per-builder cache which will result in a bit of performance hit, but we'll enable better automatic rebalancing of our CI workflows. Overall we should see a per branch reduction in cache sizes from ~17gb to ~850mb. Some preliminary investigation into this new strategy: Prior build workflow strategy on a cache miss: Download modules: ~20s Build Vault: ~40s Upload cache: ~30s Total: ~1m30s Prior build workflow strategy on a cache hit: Download and decompress modules and build cache: ~12s Build Vault: ~15s Total: ~28s New build workflow strategy on a cache miss: Download modules: ~20 Build Vault: ~40s Upload cache: ~6s Total: ~1m6s New build workflow strategy on a cache hit: Download and decompress modules: ~3s Build Vault: ~40s Total: ~43s Expected time if we used no Go caching: Download modules: ~20 Build Vault: ~40s Total: ~1m Signed-off-by: Ryan Cragun <me@ryan.ec> Co-authored-by: Ryan Cragun <me@ryan.ec>
2023-07-12 19:26:00 +00:00
echo 'go-tags=' >> "$GITHUB_OUTPUT"
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
fi
[QT-589] Use the go module cache between CI and build (#21764) (#21790) In order to reliably store Go test times in the Github Actions cache we need to reduce our cache thrashing by not using more than 10gb over all of our caches. This change reduces our cache usage significantly by sharing Go module cache between our Go CI workflows and our build workflows. We lose our per-builder cache which will result in a bit of performance hit, but we'll enable better automatic rebalancing of our CI workflows. Overall we should see a per branch reduction in cache sizes from ~17gb to ~850mb. Some preliminary investigation into this new strategy: Prior build workflow strategy on a cache miss: Download modules: ~20s Build Vault: ~40s Upload cache: ~30s Total: ~1m30s Prior build workflow strategy on a cache hit: Download and decompress modules and build cache: ~12s Build Vault: ~15s Total: ~28s New build workflow strategy on a cache miss: Download modules: ~20 Build Vault: ~40s Upload cache: ~6s Total: ~1m6s New build workflow strategy on a cache hit: Download and decompress modules: ~3s Build Vault: ~40s Total: ~43s Expected time if we used no Go caching: Download modules: ~20 Build Vault: ~40s Total: ~1m Signed-off-by: Ryan Cragun <me@ryan.ec> Co-authored-by: Ryan Cragun <me@ryan.ec>
2023-07-12 19:26:00 +00:00
- name: Ensure Go modules are cached
uses: ./.github/actions/set-up-go
with:
github-token: ${{ secrets.ELEVATED_GITHUB_TOKEN }}
no-restore: true # don't download them on a cache hit
Migrating CircleCI Jobs to GHA Workflow (#19662) * address lint reports * add diff-oss-ci and test-ui jobs to ci GHA workflow * Add actions linter workflow * Fix actions linter errors * pin 3rd party components with SHA hash and limit actionlint workflow to pull requests touching paths under .github directory * Fix actionlint runner * pin SHA hash of 3rd party components use .go-version file to provide go version to setup-go action remove unncessary ref parameter in checkout action --------- Co-authored-by: Brian Shore <bshore@hashicorp.com>
2023-03-22 19:02:06 +00:00
diff-oss-ci:
name: Diff OSS
needs:
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
- setup
Migrating CircleCI Jobs to GHA Workflow (#19662) * address lint reports * add diff-oss-ci and test-ui jobs to ci GHA workflow * Add actions linter workflow * Fix actions linter errors * pin 3rd party components with SHA hash and limit actionlint workflow to pull requests touching paths under .github directory * Fix actionlint runner * pin SHA hash of 3rd party components use .go-version file to provide go version to setup-go action remove unncessary ref parameter in checkout action --------- Co-authored-by: Brian Shore <bshore@hashicorp.com>
2023-03-22 19:02:06 +00:00
if: ${{ needs.setup.outputs.enterprise != '' && github.base_ref != '' }}
Add a new category of runners to the CI workflow… (#19807) * Add a new category of runners to the CI workflow; use new, dedicated runners on OSS; adjust runner sizes for jobs Co-authored-by: Marc Boudreau <marc.boudreau@hashicorp.com>
2023-03-30 15:41:40 +00:00
runs-on: ${{ fromJSON(needs.setup.outputs.compute-tiny) }}
Migrating CircleCI Jobs to GHA Workflow (#19662) * address lint reports * add diff-oss-ci and test-ui jobs to ci GHA workflow * Add actions linter workflow * Fix actions linter errors * pin 3rd party components with SHA hash and limit actionlint workflow to pull requests touching paths under .github directory * Fix actionlint runner * pin SHA hash of 3rd party components use .go-version file to provide go version to setup-go action remove unncessary ref parameter in checkout action --------- Co-authored-by: Brian Shore <bshore@hashicorp.com>
2023-03-22 19:02:06 +00:00
steps:
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
- uses: actions/checkout@c85c95e3d7251135ab7dc9ce3241c5835cc595a9 # v3.5.3
with:
fetch-depth: 0
- id: determine-branch
run: |
branch="${{ github.base_ref }}"
Migrating CircleCI Jobs to GHA Workflow (#19662) * address lint reports * add diff-oss-ci and test-ui jobs to ci GHA workflow * Add actions linter workflow * Fix actions linter errors * pin 3rd party components with SHA hash and limit actionlint workflow to pull requests touching paths under .github directory * Fix actionlint runner * pin SHA hash of 3rd party components use .go-version file to provide go version to setup-go action remove unncessary ref parameter in checkout action --------- Co-authored-by: Brian Shore <bshore@hashicorp.com>
2023-03-22 19:02:06 +00:00
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
if [[ $branch = release/* ]] ; then
branch=${branch%%+ent}
Migrating CircleCI Jobs to GHA Workflow (#19662) * address lint reports * add diff-oss-ci and test-ui jobs to ci GHA workflow * Add actions linter workflow * Fix actions linter errors * pin 3rd party components with SHA hash and limit actionlint workflow to pull requests touching paths under .github directory * Fix actionlint runner * pin SHA hash of 3rd party components use .go-version file to provide go version to setup-go action remove unncessary ref parameter in checkout action --------- Co-authored-by: Brian Shore <bshore@hashicorp.com>
2023-03-22 19:02:06 +00:00
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
# Add OSS remote
git config --global user.email "github-team-secret-vault-core@hashicorp.com"
git config --global user.name "hc-github-team-secret-vault-core"
git remote add oss https://github.com/hashicorp/vault.git
git fetch oss "$branch"
Migrating CircleCI Jobs to GHA Workflow (#19662) * address lint reports * add diff-oss-ci and test-ui jobs to ci GHA workflow * Add actions linter workflow * Fix actions linter errors * pin 3rd party components with SHA hash and limit actionlint workflow to pull requests touching paths under .github directory * Fix actionlint runner * pin SHA hash of 3rd party components use .go-version file to provide go version to setup-go action remove unncessary ref parameter in checkout action --------- Co-authored-by: Brian Shore <bshore@hashicorp.com>
2023-03-22 19:02:06 +00:00
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
branch="oss/$branch"
else
branch="origin/$branch"
fi
Migrating CircleCI Jobs to GHA Workflow (#19662) * address lint reports * add diff-oss-ci and test-ui jobs to ci GHA workflow * Add actions linter workflow * Fix actions linter errors * pin 3rd party components with SHA hash and limit actionlint workflow to pull requests touching paths under .github directory * Fix actionlint runner * pin SHA hash of 3rd party components use .go-version file to provide go version to setup-go action remove unncessary ref parameter in checkout action --------- Co-authored-by: Brian Shore <bshore@hashicorp.com>
2023-03-22 19:02:06 +00:00
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
echo "BRANCH=$branch" >> "$GITHUB_OUTPUT"
- id: diff
run: |
./.github/scripts/oss-diff.sh ${{ steps.determine-branch.outputs.BRANCH }} HEAD
[QT-589] Use the go module cache between CI and build (#21764) (#21790) In order to reliably store Go test times in the Github Actions cache we need to reduce our cache thrashing by not using more than 10gb over all of our caches. This change reduces our cache usage significantly by sharing Go module cache between our Go CI workflows and our build workflows. We lose our per-builder cache which will result in a bit of performance hit, but we'll enable better automatic rebalancing of our CI workflows. Overall we should see a per branch reduction in cache sizes from ~17gb to ~850mb. Some preliminary investigation into this new strategy: Prior build workflow strategy on a cache miss: Download modules: ~20s Build Vault: ~40s Upload cache: ~30s Total: ~1m30s Prior build workflow strategy on a cache hit: Download and decompress modules and build cache: ~12s Build Vault: ~15s Total: ~28s New build workflow strategy on a cache miss: Download modules: ~20 Build Vault: ~40s Upload cache: ~6s Total: ~1m6s New build workflow strategy on a cache hit: Download and decompress modules: ~3s Build Vault: ~40s Total: ~43s Expected time if we used no Go caching: Download modules: ~20 Build Vault: ~40s Total: ~1m Signed-off-by: Ryan Cragun <me@ryan.ec> Co-authored-by: Ryan Cragun <me@ryan.ec>
2023-07-12 19:26:00 +00:00
Introduce GitHub Actions CI Workflow (#19449) * Migrate subset of CircleCI ci workflow to GitHub Actions Runs test-go and test-go-remote-docker with a static splitting of test packages * [skip actions] add comment to explain the purpose of test-generate-test-package-lists.sh and what to do if it fails * change trigger to push --------- Co-authored-by: Kuba Wieczorek <kuba.wieczorek@hashicorp.com>
2023-03-06 21:57:55 +00:00
test-go:
name: Run Go tests
needs:
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
- setup
# Don't run this job for PR branches starting with:
# 'ui/', 'backport/ui/', 'docs/', or 'backport/docs/'
# OR
# the 'docs' label is present
Update the if conditions for test-go jobs in CI (#19809) * Update the if conditions for test-go jobs in CI * Fix errors in comments * Update the if condition for the UI tests
2023-03-30 20:27:42 +00:00
if: |
!startsWith(github.head_ref, 'ui/') &&
!startsWith(github.head_ref, 'backport/ui/') &&
!startsWith(github.head_ref, 'docs/') &&
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
!startsWith(github.head_ref, 'backport/docs/') &&
!contains(github.event.pull_request.labels.*.name, 'docs')
Introduce GitHub Actions CI Workflow (#19449) * Migrate subset of CircleCI ci workflow to GitHub Actions Runs test-go and test-go-remote-docker with a static splitting of test packages * [skip actions] add comment to explain the purpose of test-generate-test-package-lists.sh and what to do if it fails * change trigger to push --------- Co-authored-by: Kuba Wieczorek <kuba.wieczorek@hashicorp.com>
2023-03-06 21:57:55 +00:00
uses: ./.github/workflows/test-go.yml
with:
Use a dedicated runner for the binary-based tests. (#20377)
2023-04-27 13:41:49 +00:00
# The regular Go tests use an extra runner to execute the
# binary-dependent tests. We isolate them there so that the
# other tests aren't slowed down waiting for a binary build.
total-runners: 17
Introduce GitHub Actions CI Workflow (#19449) * Migrate subset of CircleCI ci workflow to GitHub Actions Runs test-go and test-go-remote-docker with a static splitting of test packages * [skip actions] add comment to explain the purpose of test-generate-test-package-lists.sh and what to do if it fails * change trigger to push --------- Co-authored-by: Kuba Wieczorek <kuba.wieczorek@hashicorp.com>
2023-03-06 21:57:55 +00:00
go-arch: amd64
[QT-589] Use the go module cache between CI and build (#21764) (#21790) In order to reliably store Go test times in the Github Actions cache we need to reduce our cache thrashing by not using more than 10gb over all of our caches. This change reduces our cache usage significantly by sharing Go module cache between our Go CI workflows and our build workflows. We lose our per-builder cache which will result in a bit of performance hit, but we'll enable better automatic rebalancing of our CI workflows. Overall we should see a per branch reduction in cache sizes from ~17gb to ~850mb. Some preliminary investigation into this new strategy: Prior build workflow strategy on a cache miss: Download modules: ~20s Build Vault: ~40s Upload cache: ~30s Total: ~1m30s Prior build workflow strategy on a cache hit: Download and decompress modules and build cache: ~12s Build Vault: ~15s Total: ~28s New build workflow strategy on a cache miss: Download modules: ~20 Build Vault: ~40s Upload cache: ~6s Total: ~1m6s New build workflow strategy on a cache hit: Download and decompress modules: ~3s Build Vault: ~40s Total: ~43s Expected time if we used no Go caching: Download modules: ~20 Build Vault: ~40s Total: ~1m Signed-off-by: Ryan Cragun <me@ryan.ec> Co-authored-by: Ryan Cragun <me@ryan.ec>
2023-07-12 19:26:00 +00:00
go-tags: '${{ needs.setup.outputs.go-tags }},deadlock'
Add a new category of runners to the CI workflow… (#19807) * Add a new category of runners to the CI workflow; use new, dedicated runners on OSS; adjust runner sizes for jobs Co-authored-by: Marc Boudreau <marc.boudreau@hashicorp.com>
2023-03-30 15:41:40 +00:00
runs-on: ${{ needs.setup.outputs.compute-larger }}
Add a GHA job running Go tests with race detection enabled to the CI … (#19561) * Add a GHA job running Go tests with race detection enabled to the CI workflow * Incorporate logic from test-go-race into the test-go testing matrix * Make test-go testing matrix job names more meaningful * Fix some a bug in script's logic * Experiment: bump wait time in the failing TestLoginMFASinglePhase test to see if that makes a difference * Lower the wait time in TestLoginMFASinglePhase * Change the wait time in TestLoginMFASinglePhase to 15 * Add more detail to test-go testing matrix job names * Test whether we already have access to larger runners * Run Go tests with enabled data race detection from a separate job than the standard suite of tests * Tweak runner sizes for OSS * Try rebalancing test buckets * Change instance type for larger ENT runners * Undo rebalancing of test buckets as it changed nothing * Change instance type for larger OSS runners * Change the way we generate names for matrix jobs * Consolidate the Go build tags variables, update them to use comma as a separator and fix the if statement in test-go * Fix a typo
2023-03-21 18:13:40 +00:00
enterprise: ${{ needs.setup.outputs.enterprise }}
secrets: inherit
[QT-589] Use the go module cache between CI and build (#21764) (#21790) In order to reliably store Go test times in the Github Actions cache we need to reduce our cache thrashing by not using more than 10gb over all of our caches. This change reduces our cache usage significantly by sharing Go module cache between our Go CI workflows and our build workflows. We lose our per-builder cache which will result in a bit of performance hit, but we'll enable better automatic rebalancing of our CI workflows. Overall we should see a per branch reduction in cache sizes from ~17gb to ~850mb. Some preliminary investigation into this new strategy: Prior build workflow strategy on a cache miss: Download modules: ~20s Build Vault: ~40s Upload cache: ~30s Total: ~1m30s Prior build workflow strategy on a cache hit: Download and decompress modules and build cache: ~12s Build Vault: ~15s Total: ~28s New build workflow strategy on a cache miss: Download modules: ~20 Build Vault: ~40s Upload cache: ~6s Total: ~1m6s New build workflow strategy on a cache hit: Download and decompress modules: ~3s Build Vault: ~40s Total: ~43s Expected time if we used no Go caching: Download modules: ~20 Build Vault: ~40s Total: ~1m Signed-off-by: Ryan Cragun <me@ryan.ec> Co-authored-by: Ryan Cragun <me@ryan.ec>
2023-07-12 19:26:00 +00:00
Add a GHA job running Go tests with race detection enabled to the CI … (#19561) * Add a GHA job running Go tests with race detection enabled to the CI workflow * Incorporate logic from test-go-race into the test-go testing matrix * Make test-go testing matrix job names more meaningful * Fix some a bug in script's logic * Experiment: bump wait time in the failing TestLoginMFASinglePhase test to see if that makes a difference * Lower the wait time in TestLoginMFASinglePhase * Change the wait time in TestLoginMFASinglePhase to 15 * Add more detail to test-go testing matrix job names * Test whether we already have access to larger runners * Run Go tests with enabled data race detection from a separate job than the standard suite of tests * Tweak runner sizes for OSS * Try rebalancing test buckets * Change instance type for larger ENT runners * Undo rebalancing of test buckets as it changed nothing * Change instance type for larger OSS runners * Change the way we generate names for matrix jobs * Consolidate the Go build tags variables, update them to use comma as a separator and fix the if statement in test-go * Fix a typo
2023-03-21 18:13:40 +00:00
test-go-race:
name: Run Go tests with data race detection
needs:
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
- setup
# Don't run this job for PR branches starting with:
# 'ui/', 'backport/ui/', 'docs/', or 'backport/docs/'
# OR
# the 'docs' label is present
Update the if conditions for test-go jobs in CI (#19809) * Update the if conditions for test-go jobs in CI * Fix errors in comments * Update the if condition for the UI tests
2023-03-30 20:27:42 +00:00
if: |
Don't run build workflow on draft PRs. (#20443)
2023-05-01 17:52:41 +00:00
github.event.pull_request.draft == false &&
Update the if conditions for test-go jobs in CI (#19809) * Update the if conditions for test-go jobs in CI * Fix errors in comments * Update the if condition for the UI tests
2023-03-30 20:27:42 +00:00
!startsWith(github.head_ref, 'ui/') &&
!startsWith(github.head_ref, 'backport/ui/') &&
!startsWith(github.head_ref, 'docs/') &&
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
!startsWith(github.head_ref, 'backport/docs/') &&
!contains(github.event.pull_request.labels.*.name, 'docs')
Add a GHA job running Go tests with race detection enabled to the CI … (#19561) * Add a GHA job running Go tests with race detection enabled to the CI workflow * Incorporate logic from test-go-race into the test-go testing matrix * Make test-go testing matrix job names more meaningful * Fix some a bug in script's logic * Experiment: bump wait time in the failing TestLoginMFASinglePhase test to see if that makes a difference * Lower the wait time in TestLoginMFASinglePhase * Change the wait time in TestLoginMFASinglePhase to 15 * Add more detail to test-go testing matrix job names * Test whether we already have access to larger runners * Run Go tests with enabled data race detection from a separate job than the standard suite of tests * Tweak runner sizes for OSS * Try rebalancing test buckets * Change instance type for larger ENT runners * Undo rebalancing of test buckets as it changed nothing * Change instance type for larger OSS runners * Change the way we generate names for matrix jobs * Consolidate the Go build tags variables, update them to use comma as a separator and fix the if statement in test-go * Fix a typo
2023-03-21 18:13:40 +00:00
uses: ./.github/workflows/test-go.yml
with:
Add the FIPS testing job to GitHub Actions CI workflow (#19742)
2023-03-24 17:17:21 +00:00
total-runners: 16
env-vars: |
{
"VAULT_CI_GO_TEST_RACE": 1
}
Add a GHA job running Go tests with race detection enabled to the CI … (#19561) * Add a GHA job running Go tests with race detection enabled to the CI workflow * Incorporate logic from test-go-race into the test-go testing matrix * Make test-go testing matrix job names more meaningful * Fix some a bug in script's logic * Experiment: bump wait time in the failing TestLoginMFASinglePhase test to see if that makes a difference * Lower the wait time in TestLoginMFASinglePhase * Change the wait time in TestLoginMFASinglePhase to 15 * Add more detail to test-go testing matrix job names * Test whether we already have access to larger runners * Run Go tests with enabled data race detection from a separate job than the standard suite of tests * Tweak runner sizes for OSS * Try rebalancing test buckets * Change instance type for larger ENT runners * Undo rebalancing of test buckets as it changed nothing * Change instance type for larger OSS runners * Change the way we generate names for matrix jobs * Consolidate the Go build tags variables, update them to use comma as a separator and fix the if statement in test-go * Fix a typo
2023-03-21 18:13:40 +00:00
extra-flags: '-race'
go-arch: amd64
[QT-589] Use the go module cache between CI and build (#21764) (#21790) In order to reliably store Go test times in the Github Actions cache we need to reduce our cache thrashing by not using more than 10gb over all of our caches. This change reduces our cache usage significantly by sharing Go module cache between our Go CI workflows and our build workflows. We lose our per-builder cache which will result in a bit of performance hit, but we'll enable better automatic rebalancing of our CI workflows. Overall we should see a per branch reduction in cache sizes from ~17gb to ~850mb. Some preliminary investigation into this new strategy: Prior build workflow strategy on a cache miss: Download modules: ~20s Build Vault: ~40s Upload cache: ~30s Total: ~1m30s Prior build workflow strategy on a cache hit: Download and decompress modules and build cache: ~12s Build Vault: ~15s Total: ~28s New build workflow strategy on a cache miss: Download modules: ~20 Build Vault: ~40s Upload cache: ~6s Total: ~1m6s New build workflow strategy on a cache hit: Download and decompress modules: ~3s Build Vault: ~40s Total: ~43s Expected time if we used no Go caching: Download modules: ~20 Build Vault: ~40s Total: ~1m Signed-off-by: Ryan Cragun <me@ryan.ec> Co-authored-by: Ryan Cragun <me@ryan.ec>
2023-07-12 19:26:00 +00:00
go-tags: ${{ needs.setup.outputs.go-tags }}
Add a new category of runners to the CI workflow… (#19807) * Add a new category of runners to the CI workflow; use new, dedicated runners on OSS; adjust runner sizes for jobs Co-authored-by: Marc Boudreau <marc.boudreau@hashicorp.com>
2023-03-30 15:41:40 +00:00
runs-on: ${{ needs.setup.outputs.compute-huge }}
Introduce GitHub Actions CI Workflow (#19449) * Migrate subset of CircleCI ci workflow to GitHub Actions Runs test-go and test-go-remote-docker with a static splitting of test packages * [skip actions] add comment to explain the purpose of test-generate-test-package-lists.sh and what to do if it fails * change trigger to push --------- Co-authored-by: Kuba Wieczorek <kuba.wieczorek@hashicorp.com>
2023-03-06 21:57:55 +00:00
enterprise: ${{ needs.setup.outputs.enterprise }}
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
name: "-race"
Introduce GitHub Actions CI Workflow (#19449) * Migrate subset of CircleCI ci workflow to GitHub Actions Runs test-go and test-go-remote-docker with a static splitting of test packages * [skip actions] add comment to explain the purpose of test-generate-test-package-lists.sh and what to do if it fails * change trigger to push --------- Co-authored-by: Kuba Wieczorek <kuba.wieczorek@hashicorp.com>
2023-03-06 21:57:55 +00:00
secrets: inherit
[QT-589] Use the go module cache between CI and build (#21764) (#21790) In order to reliably store Go test times in the Github Actions cache we need to reduce our cache thrashing by not using more than 10gb over all of our caches. This change reduces our cache usage significantly by sharing Go module cache between our Go CI workflows and our build workflows. We lose our per-builder cache which will result in a bit of performance hit, but we'll enable better automatic rebalancing of our CI workflows. Overall we should see a per branch reduction in cache sizes from ~17gb to ~850mb. Some preliminary investigation into this new strategy: Prior build workflow strategy on a cache miss: Download modules: ~20s Build Vault: ~40s Upload cache: ~30s Total: ~1m30s Prior build workflow strategy on a cache hit: Download and decompress modules and build cache: ~12s Build Vault: ~15s Total: ~28s New build workflow strategy on a cache miss: Download modules: ~20 Build Vault: ~40s Upload cache: ~6s Total: ~1m6s New build workflow strategy on a cache hit: Download and decompress modules: ~3s Build Vault: ~40s Total: ~43s Expected time if we used no Go caching: Download modules: ~20 Build Vault: ~40s Total: ~1m Signed-off-by: Ryan Cragun <me@ryan.ec> Co-authored-by: Ryan Cragun <me@ryan.ec>
2023-07-12 19:26:00 +00:00
Add the FIPS testing job to GitHub Actions CI workflow (#19742)
2023-03-24 17:17:21 +00:00
test-go-fips:
name: Run Go tests with FIPS configuration
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
# Only run this job for the enterprise repo if the PR branch doesn't start with:
# 'ui/', 'backport/ui/', 'docs/', or 'backport/docs/'
# OR
# the 'docs' label is not present
Add the FIPS testing job to GitHub Actions CI workflow (#19742)
2023-03-24 17:17:21 +00:00
if: |
Don't run build workflow on draft PRs. (#20443)
2023-05-01 17:52:41 +00:00
github.event.pull_request.draft == false &&
Add the FIPS testing job to GitHub Actions CI workflow (#19742)
2023-03-24 17:17:21 +00:00
needs.setup.outputs.enterprise == 1 &&
Update the if conditions for test-go jobs in CI (#19809) * Update the if conditions for test-go jobs in CI * Fix errors in comments * Update the if condition for the UI tests
2023-03-30 20:27:42 +00:00
!startsWith(github.head_ref, 'ui/') &&
!startsWith(github.head_ref, 'backport/ui/') &&
!startsWith(github.head_ref, 'docs/') &&
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
!startsWith(github.head_ref, 'backport/docs/') &&
!contains(github.event.pull_request.labels.*.name, 'docs')
Add the FIPS testing job to GitHub Actions CI workflow (#19742)
2023-03-24 17:17:21 +00:00
needs:
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
- setup
Add the FIPS testing job to GitHub Actions CI workflow (#19742)
2023-03-24 17:17:21 +00:00
uses: ./.github/workflows/test-go.yml
with:
total-runners: 16
env-vars: |
{
"GOEXPERIMENT": "boringcrypto"
}
go-arch: amd64
[QT-589] Use the go module cache between CI and build (#21764) (#21790) In order to reliably store Go test times in the Github Actions cache we need to reduce our cache thrashing by not using more than 10gb over all of our caches. This change reduces our cache usage significantly by sharing Go module cache between our Go CI workflows and our build workflows. We lose our per-builder cache which will result in a bit of performance hit, but we'll enable better automatic rebalancing of our CI workflows. Overall we should see a per branch reduction in cache sizes from ~17gb to ~850mb. Some preliminary investigation into this new strategy: Prior build workflow strategy on a cache miss: Download modules: ~20s Build Vault: ~40s Upload cache: ~30s Total: ~1m30s Prior build workflow strategy on a cache hit: Download and decompress modules and build cache: ~12s Build Vault: ~15s Total: ~28s New build workflow strategy on a cache miss: Download modules: ~20 Build Vault: ~40s Upload cache: ~6s Total: ~1m6s New build workflow strategy on a cache hit: Download and decompress modules: ~3s Build Vault: ~40s Total: ~43s Expected time if we used no Go caching: Download modules: ~20 Build Vault: ~40s Total: ~1m Signed-off-by: Ryan Cragun <me@ryan.ec> Co-authored-by: Ryan Cragun <me@ryan.ec>
2023-07-12 19:26:00 +00:00
go-tags: '${{ needs.setup.outputs.go-tags }},deadlock,cgo,fips,fips_140_2'
Add a new category of runners to the CI workflow… (#19807) * Add a new category of runners to the CI workflow; use new, dedicated runners on OSS; adjust runner sizes for jobs Co-authored-by: Marc Boudreau <marc.boudreau@hashicorp.com>
2023-03-30 15:41:40 +00:00
runs-on: ${{ needs.setup.outputs.compute-larger }}
Add the FIPS testing job to GitHub Actions CI workflow (#19742)
2023-03-24 17:17:21 +00:00
enterprise: ${{ needs.setup.outputs.enterprise }}
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
name: "-fips"
Add the FIPS testing job to GitHub Actions CI workflow (#19742)
2023-03-24 17:17:21 +00:00
secrets: inherit
[QT-589] Use the go module cache between CI and build (#21764) (#21790) In order to reliably store Go test times in the Github Actions cache we need to reduce our cache thrashing by not using more than 10gb over all of our caches. This change reduces our cache usage significantly by sharing Go module cache between our Go CI workflows and our build workflows. We lose our per-builder cache which will result in a bit of performance hit, but we'll enable better automatic rebalancing of our CI workflows. Overall we should see a per branch reduction in cache sizes from ~17gb to ~850mb. Some preliminary investigation into this new strategy: Prior build workflow strategy on a cache miss: Download modules: ~20s Build Vault: ~40s Upload cache: ~30s Total: ~1m30s Prior build workflow strategy on a cache hit: Download and decompress modules and build cache: ~12s Build Vault: ~15s Total: ~28s New build workflow strategy on a cache miss: Download modules: ~20 Build Vault: ~40s Upload cache: ~6s Total: ~1m6s New build workflow strategy on a cache hit: Download and decompress modules: ~3s Build Vault: ~40s Total: ~43s Expected time if we used no Go caching: Download modules: ~20 Build Vault: ~40s Total: ~1m Signed-off-by: Ryan Cragun <me@ryan.ec> Co-authored-by: Ryan Cragun <me@ryan.ec>
2023-07-12 19:26:00 +00:00
Migrating CircleCI Jobs to GHA Workflow (#19662) * address lint reports * add diff-oss-ci and test-ui jobs to ci GHA workflow * Add actions linter workflow * Fix actions linter errors * pin 3rd party components with SHA hash and limit actionlint workflow to pull requests touching paths under .github directory * Fix actionlint runner * pin SHA hash of 3rd party components use .go-version file to provide go version to setup-go action remove unncessary ref parameter in checkout action --------- Co-authored-by: Brian Shore <bshore@hashicorp.com>
2023-03-22 19:02:06 +00:00
test-ui:
name: Test UI
Update the if conditions for test-go jobs in CI (#19809) * Update the if conditions for test-go jobs in CI * Fix errors in comments * Update the if condition for the UI tests
2023-03-30 20:27:42 +00:00
# The test-ui job is only run on:
# - pushes to main and branches starting with "release/"
# - PRs where the branch starts with "ui/", "backport/ui/", "merge", or when base branch starts with "release/"
Run UI tests on PRs with "ui" label (#20209) * add conditional for label * VAULT-14643 link jira
2023-04-18 19:03:35 +00:00
# - PRs with the "ui" label on github
Update the if conditions for test-go jobs in CI (#19809) * Update the if conditions for test-go jobs in CI * Fix errors in comments * Update the if condition for the UI tests
2023-03-30 20:27:42 +00:00
if: |
github.ref_name == 'main' ||
startsWith(github.ref_name, 'release/') ||
startsWith(github.head_ref, 'ui/') ||
startsWith(github.head_ref, 'backport/ui/') ||
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
startsWith(github.head_ref, 'merge') ||
Run UI tests on PRs with "ui" label (#20209) * add conditional for label * VAULT-14643 link jira
2023-04-18 19:03:35 +00:00
contains(github.event.pull_request.labels.*.name, 'ui')
Migrating CircleCI Jobs to GHA Workflow (#19662) * address lint reports * add diff-oss-ci and test-ui jobs to ci GHA workflow * Add actions linter workflow * Fix actions linter errors * pin 3rd party components with SHA hash and limit actionlint workflow to pull requests touching paths under .github directory * Fix actionlint runner * pin SHA hash of 3rd party components use .go-version file to provide go version to setup-go action remove unncessary ref parameter in checkout action --------- Co-authored-by: Brian Shore <bshore@hashicorp.com>
2023-03-22 19:02:06 +00:00
needs:
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
- setup
Migrating CircleCI Jobs to GHA Workflow (#19662) * address lint reports * add diff-oss-ci and test-ui jobs to ci GHA workflow * Add actions linter workflow * Fix actions linter errors * pin 3rd party components with SHA hash and limit actionlint workflow to pull requests touching paths under .github directory * Fix actionlint runner * pin SHA hash of 3rd party components use .go-version file to provide go version to setup-go action remove unncessary ref parameter in checkout action --------- Co-authored-by: Brian Shore <bshore@hashicorp.com>
2023-03-22 19:02:06 +00:00
permissions:
id-token: write
contents: read
Add a new category of runners to the CI workflow… (#19807) * Add a new category of runners to the CI workflow; use new, dedicated runners on OSS; adjust runner sizes for jobs Co-authored-by: Marc Boudreau <marc.boudreau@hashicorp.com>
2023-03-30 15:41:40 +00:00
runs-on: ${{ fromJSON(needs.setup.outputs.compute-larger) }}
Migrating CircleCI Jobs to GHA Workflow (#19662) * address lint reports * add diff-oss-ci and test-ui jobs to ci GHA workflow * Add actions linter workflow * Fix actions linter errors * pin 3rd party components with SHA hash and limit actionlint workflow to pull requests touching paths under .github directory * Fix actionlint runner * pin SHA hash of 3rd party components use .go-version file to provide go version to setup-go action remove unncessary ref parameter in checkout action --------- Co-authored-by: Brian Shore <bshore@hashicorp.com>
2023-03-22 19:02:06 +00:00
steps:
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
- uses: actions/checkout@c85c95e3d7251135ab7dc9ce3241c5835cc595a9 # v3.5.3
[QT-589] Use the go module cache between CI and build (#21764) (#21790) In order to reliably store Go test times in the Github Actions cache we need to reduce our cache thrashing by not using more than 10gb over all of our caches. This change reduces our cache usage significantly by sharing Go module cache between our Go CI workflows and our build workflows. We lose our per-builder cache which will result in a bit of performance hit, but we'll enable better automatic rebalancing of our CI workflows. Overall we should see a per branch reduction in cache sizes from ~17gb to ~850mb. Some preliminary investigation into this new strategy: Prior build workflow strategy on a cache miss: Download modules: ~20s Build Vault: ~40s Upload cache: ~30s Total: ~1m30s Prior build workflow strategy on a cache hit: Download and decompress modules and build cache: ~12s Build Vault: ~15s Total: ~28s New build workflow strategy on a cache miss: Download modules: ~20 Build Vault: ~40s Upload cache: ~6s Total: ~1m6s New build workflow strategy on a cache hit: Download and decompress modules: ~3s Build Vault: ~40s Total: ~43s Expected time if we used no Go caching: Download modules: ~20 Build Vault: ~40s Total: ~1m Signed-off-by: Ryan Cragun <me@ryan.ec> Co-authored-by: Ryan Cragun <me@ryan.ec>
2023-07-12 19:26:00 +00:00
- uses: ./.github/actions/set-up-go
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
with:
[QT-589] Use the go module cache between CI and build (#21764) (#21790) In order to reliably store Go test times in the Github Actions cache we need to reduce our cache thrashing by not using more than 10gb over all of our caches. This change reduces our cache usage significantly by sharing Go module cache between our Go CI workflows and our build workflows. We lose our per-builder cache which will result in a bit of performance hit, but we'll enable better automatic rebalancing of our CI workflows. Overall we should see a per branch reduction in cache sizes from ~17gb to ~850mb. Some preliminary investigation into this new strategy: Prior build workflow strategy on a cache miss: Download modules: ~20s Build Vault: ~40s Upload cache: ~30s Total: ~1m30s Prior build workflow strategy on a cache hit: Download and decompress modules and build cache: ~12s Build Vault: ~15s Total: ~28s New build workflow strategy on a cache miss: Download modules: ~20 Build Vault: ~40s Upload cache: ~6s Total: ~1m6s New build workflow strategy on a cache hit: Download and decompress modules: ~3s Build Vault: ~40s Total: ~43s Expected time if we used no Go caching: Download modules: ~20 Build Vault: ~40s Total: ~1m Signed-off-by: Ryan Cragun <me@ryan.ec> Co-authored-by: Ryan Cragun <me@ryan.ec>
2023-07-12 19:26:00 +00:00
github-token: ${{ secrets.ELEVATED_GITHUB_TOKEN }}
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
# Setup node.js without caching to allow running npm install -g yarn (next step)
- uses: actions/setup-node@64ed1c7eab4cce3362f8c340dee64e5eaeef8f7c # v3.6.0
with:
node-version-file: './ui/package.json'
- id: install-yarn
run: |
npm install -g yarn
# Setup node.js with caching using the yarn.lock file
- uses: actions/setup-node@64ed1c7eab4cce3362f8c340dee64e5eaeef8f7c # v3.6.0
with:
node-version-file: './ui/package.json'
cache: yarn
cache-dependency-path: ui/yarn.lock
- id: install-browser
uses: browser-actions/setup-chrome@c485fa3bab6be59dce18dbc18ef6ab7cbc8ff5f1 # v1.2.0
- id: ui-dependencies
name: ui-dependencies
working-directory: ./ui
run: |
yarn install --frozen-lockfile
npm rebuild node-sass
- id: vault-auth
name: Authenticate to Vault
if: github.repository == 'hashicorp/vault-enterprise'
run: vault-auth
- id: secrets
name: Fetch secrets
if: github.repository == 'hashicorp/vault-enterprise'
uses: hashicorp/vault-action@130d1f5f4fe645bb6c83e4225c04d64cfb62de6e
with:
Migrating CircleCI Jobs to GHA Workflow (#19662) * address lint reports * add diff-oss-ci and test-ui jobs to ci GHA workflow * Add actions linter workflow * Fix actions linter errors * pin 3rd party components with SHA hash and limit actionlint workflow to pull requests touching paths under .github directory * Fix actionlint runner * pin SHA hash of 3rd party components use .go-version file to provide go version to setup-go action remove unncessary ref parameter in checkout action --------- Co-authored-by: Brian Shore <bshore@hashicorp.com>
2023-03-22 19:02:06 +00:00
url: ${{ steps.vault-auth.outputs.addr }}
caCertificate: ${{ steps.vault-auth.outputs.ca_certificate }}
token: ${{ steps.vault-auth.outputs.token }}
secrets: |
kv/data/github/hashicorp/vault-enterprise/github-token token | PRIVATE_REPO_GITHUB_TOKEN;
kv/data/github/hashicorp/vault-enterprise/license license_1 | VAULT_LICENSE;
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
- id: setup-git
name: Setup Git
if: github.repository == 'hashicorp/vault-enterprise'
run: |
git config --global url."https://${{ steps.secrets.outputs.PRIVATE_REPO_GITHUB_TOKEN }}@github.com".insteadOf https://github.com
- id: build-go-dev
name: build-go-dev
run: |
rm -rf ./pkg
mkdir ./pkg
Migrating CircleCI Jobs to GHA Workflow (#19662) * address lint reports * add diff-oss-ci and test-ui jobs to ci GHA workflow * Add actions linter workflow * Fix actions linter errors * pin 3rd party components with SHA hash and limit actionlint workflow to pull requests touching paths under .github directory * Fix actionlint runner * pin SHA hash of 3rd party components use .go-version file to provide go version to setup-go action remove unncessary ref parameter in checkout action --------- Co-authored-by: Brian Shore <bshore@hashicorp.com>
2023-03-22 19:02:06 +00:00
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
make ci-bootstrap dev
- id: test-ui
name: test-ui
env:
VAULT_LICENSE: ${{ steps.secrets.outputs.VAULT_LICENSE }}
run: |
export PATH="${PWD}/bin:${PATH}"
Migrating CircleCI Jobs to GHA Workflow (#19662) * address lint reports * add diff-oss-ci and test-ui jobs to ci GHA workflow * Add actions linter workflow * Fix actions linter errors * pin 3rd party components with SHA hash and limit actionlint workflow to pull requests touching paths under .github directory * Fix actionlint runner * pin SHA hash of 3rd party components use .go-version file to provide go version to setup-go action remove unncessary ref parameter in checkout action --------- Co-authored-by: Brian Shore <bshore@hashicorp.com>
2023-03-22 19:02:06 +00:00
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
if [ "${{ github.repository }}" == 'hashicorp/vault' ] ; then
export VAULT_LICENSE="${{ secrets.VAULT_LICENSE }}"
fi
Migrating CircleCI Jobs to GHA Workflow (#19662) * address lint reports * add diff-oss-ci and test-ui jobs to ci GHA workflow * Add actions linter workflow * Fix actions linter errors * pin 3rd party components with SHA hash and limit actionlint workflow to pull requests touching paths under .github directory * Fix actionlint runner * pin SHA hash of 3rd party components use .go-version file to provide go version to setup-go action remove unncessary ref parameter in checkout action --------- Co-authored-by: Brian Shore <bshore@hashicorp.com>
2023-03-22 19:02:06 +00:00
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
# Run Ember tests
cd ui
mkdir -p test-results/qunit
yarn test:oss
- uses: actions/upload-artifact@0b7f8abb1508181956e8e162db84b466c27e18ce # v3.1.2
with:
name: test-results-ui
path: ui/test-results
if: success() || failure()
VAULT-17592 Extract failed Go test results across runners (#21625) (#21672) Co-authored-by: Kuba Wieczorek <kuba.wieczorek@hashicorp.com>
2023-07-07 17:52:01 +00:00
- uses: test-summary/action@62bc5c68de2a6a0d02039763b8c754569df99e3f # TSCCR: no entry for repository "test-summary/action"
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
with:
paths: "ui/test-results/qunit/results.xml"
show: "fail"
if: always()
[QT-589] Use the go module cache between CI and build (#21764) (#21790) In order to reliably store Go test times in the Github Actions cache we need to reduce our cache thrashing by not using more than 10gb over all of our caches. This change reduces our cache usage significantly by sharing Go module cache between our Go CI workflows and our build workflows. We lose our per-builder cache which will result in a bit of performance hit, but we'll enable better automatic rebalancing of our CI workflows. Overall we should see a per branch reduction in cache sizes from ~17gb to ~850mb. Some preliminary investigation into this new strategy: Prior build workflow strategy on a cache miss: Download modules: ~20s Build Vault: ~40s Upload cache: ~30s Total: ~1m30s Prior build workflow strategy on a cache hit: Download and decompress modules and build cache: ~12s Build Vault: ~15s Total: ~28s New build workflow strategy on a cache miss: Download modules: ~20 Build Vault: ~40s Upload cache: ~6s Total: ~1m6s New build workflow strategy on a cache hit: Download and decompress modules: ~3s Build Vault: ~40s Total: ~43s Expected time if we used no Go caching: Download modules: ~20 Build Vault: ~40s Total: ~1m Signed-off-by: Ryan Cragun <me@ryan.ec> Co-authored-by: Ryan Cragun <me@ryan.ec>
2023-07-12 19:26:00 +00:00
Create Job to Track All Required Test Jobs (#19743) * add tests-completed job to track all matrix jobs completed successfully * add dependency on setup job for tests-completed job
2023-03-24 14:39:17 +00:00
tests-completed:
needs:
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
- setup
- test-go
- test-ui
[QT-589] Use the go module cache between CI and build (#21764) (#21790) In order to reliably store Go test times in the Github Actions cache we need to reduce our cache thrashing by not using more than 10gb over all of our caches. This change reduces our cache usage significantly by sharing Go module cache between our Go CI workflows and our build workflows. We lose our per-builder cache which will result in a bit of performance hit, but we'll enable better automatic rebalancing of our CI workflows. Overall we should see a per branch reduction in cache sizes from ~17gb to ~850mb. Some preliminary investigation into this new strategy: Prior build workflow strategy on a cache miss: Download modules: ~20s Build Vault: ~40s Upload cache: ~30s Total: ~1m30s Prior build workflow strategy on a cache hit: Download and decompress modules and build cache: ~12s Build Vault: ~15s Total: ~28s New build workflow strategy on a cache miss: Download modules: ~20 Build Vault: ~40s Upload cache: ~6s Total: ~1m6s New build workflow strategy on a cache hit: Download and decompress modules: ~3s Build Vault: ~40s Total: ~43s Expected time if we used no Go caching: Download modules: ~20 Build Vault: ~40s Total: ~1m Signed-off-by: Ryan Cragun <me@ryan.ec> Co-authored-by: Ryan Cragun <me@ryan.ec>
2023-07-12 19:26:00 +00:00
if: always()
Add a new category of runners to the CI workflow… (#19807) * Add a new category of runners to the CI workflow; use new, dedicated runners on OSS; adjust runner sizes for jobs Co-authored-by: Marc Boudreau <marc.boudreau@hashicorp.com>
2023-03-30 15:41:40 +00:00
runs-on: ${{ fromJSON(needs.setup.outputs.compute-tiny) }}
Create Job to Track All Required Test Jobs (#19743) * add tests-completed job to track all matrix jobs completed successfully * add dependency on setup job for tests-completed job
2023-03-24 14:39:17 +00:00
steps:
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
- run: |
tr -d '\n' <<< '${{ toJSON(needs.*.result) }}' | grep -q -v -E '(failure|cancelled)'
[QT-589] Use the go module cache between CI and build (#21764) (#21790) In order to reliably store Go test times in the Github Actions cache we need to reduce our cache thrashing by not using more than 10gb over all of our caches. This change reduces our cache usage significantly by sharing Go module cache between our Go CI workflows and our build workflows. We lose our per-builder cache which will result in a bit of performance hit, but we'll enable better automatic rebalancing of our CI workflows. Overall we should see a per branch reduction in cache sizes from ~17gb to ~850mb. Some preliminary investigation into this new strategy: Prior build workflow strategy on a cache miss: Download modules: ~20s Build Vault: ~40s Upload cache: ~30s Total: ~1m30s Prior build workflow strategy on a cache hit: Download and decompress modules and build cache: ~12s Build Vault: ~15s Total: ~28s New build workflow strategy on a cache miss: Download modules: ~20 Build Vault: ~40s Upload cache: ~6s Total: ~1m6s New build workflow strategy on a cache hit: Download and decompress modules: ~3s Build Vault: ~40s Total: ~43s Expected time if we used no Go caching: Download modules: ~20 Build Vault: ~40s Total: ~1m Signed-off-by: Ryan Cragun <me@ryan.ec> Co-authored-by: Ryan Cragun <me@ryan.ec>
2023-07-12 19:26:00 +00:00
VAULT-17592 Extract failed Go test results across runners (#21625) (#21672) Co-authored-by: Kuba Wieczorek <kuba.wieczorek@hashicorp.com>
2023-07-07 17:52:01 +00:00
notify-tests-completed-failures-oss:
if: ${{ always() && github.repository == 'hashicorp/vault' && needs.tests-completed.result == 'failure' && (github.ref_name == 'main' || startsWith(github.ref_name, 'release/')) }}
[QT-576] Optimize build workflow (#21486) (#21601) Improve our build workflow execution time by using custom runners, improved caching and conditional Web UI builds. Runners ------- We improve our build times[0] by using larger custom runners[1] when building the UI and Vault. Caching ------- We improve Vault caching by keeping a cache for each build job. This strategy has the following properties which should result in faster build times when `go.sum` hasn't been changed from prior builds, or when a pull request is retried or updated after a prior successful build: * Builds will restore cached Go modules and Go build cache according to the Go version, platform, architecture, go tags, and hash of `go.sum` that relates to each individual build workflow. This reduces the amount of time it will take to download the cache on hits and upload the cache on misses. * Parallel build workflows won't clobber each others build cache. This results in much faster compile times after cache hits because the Go compiler can reuse the platform, architecture, and tag specific build cache that it created on prior runs. * Older modules and build cache will not be uploaded when creating a new cache. This should result in lean cache sizes on an ongoing basis. * On cache misses we will have to upload our compressed module and build cache. This will slightly extend the build time for pull requests that modify `go.sum`. Web UI ------ We no longer build the web UI in every build workflow. Instead we separate the UI building into its own workflow and cache the resulting assets. The same UI assets are restored from cache during build worklows. This strategy has the following properties: * If the `ui` directory has not changed from prior builds we'll restore `http/web_ui` from cache and skip building the UI for no reason. * We continue to use the built-in `yarn` caching functionality in `action/setup-node`. The default mode saves the `yarn` global cache. to improve UI build times if the cache has not been modified. Changes ------- * Add per platform/archicture Go module and build caching * Move UI building into a separate job and cache the result * Restore UI cache during build * Pin workflows Notes ----- [0] https://hashicorp.atlassian.net/browse/QT-578 [1] https://github.com/hashicorp/vault/actions/runs/5415830307/jobs/9844829929 Signed-off-by: Ryan Cragun <me@ryan.ec>
2023-07-05 21:19:49 +00:00
runs-on: ubuntu-latest
permissions:
id-token: write
contents: read
strategy:
fail-fast: false
needs:
- tests-completed
steps:
- name: send-notification
uses: slackapi/slack-github-action@e28cf165c92ffef168d23c5c9000cffc8a25e117 # v1.24.0
# We intentionally aren't using the following here since it's from an internal repo
# uses: hashicorp/cloud-gha-slack-notifier@730a033037b8e603adf99ebd3085f0fdfe75e2f4 #v1
env:
SLACK_BOT_TOKEN: ${{ secrets.SLACK_BOT_TOKEN }}
with:
channel-id: "C05AABYEA9Y" # sent to #feed-vault-ci-official
payload: |
{"text":"OSS test failures on ${{ github.ref_name }}","blocks":[{"type":"header","text":{"type":"plain_text","text":":rotating_light: OSS test failures :rotating_light:","emoji":true}},{"type":"divider"},{"type":"section","text":{"type":"mrkdwn","text":"test(s) failed on ${{ github.ref_name }}"},"accessory":{"type":"button","text":{"type":"plain_text","text":"View Failing Workflow","emoji":true},"url":"${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}"}}]}
VAULT-17592 Extract failed Go test results across runners (#21625) (#21672) Co-authored-by: Kuba Wieczorek <kuba.wieczorek@hashicorp.com>
2023-07-07 17:52:01 +00:00
notify-tests-completed-failures-ent:
if: ${{ always() && github.repository == 'hashicorp/vault-enterprise' && needs.tests-completed.result == 'failure' && (github.ref_name == 'main' || startsWith(github.ref_name, 'release/')) }}
runs-on: ['self-hosted', 'linux', 'small']
permissions:
id-token: write
contents: read
strategy:
fail-fast: false
needs:
- tests-completed
steps:
- id: vault-auth
name: Vault Authenticate
run: vault-auth
- id: secrets
name: Fetch Vault Secrets
uses: hashicorp/vault-action@130d1f5f4fe645bb6c83e4225c04d64cfb62de6e
with:
url: ${{ steps.vault-auth.outputs.addr }}
caCertificate: ${{ steps.vault-auth.outputs.ca_certificate }}
token: ${{ steps.vault-auth.outputs.token }}
secrets: |
kv/data/github/${{ github.repository }}/github_actions_notifications_bot token | SLACK_BOT_TOKEN;
- name: send-notification
uses: hashicorp/cloud-gha-slack-notifier@730a033037b8e603adf99ebd3085f0fdfe75e2f4 #v1
with:
channel-id: "C05AABYEA9Y" # sent to #feed-vault-ci-official
slack-bot-token: ${{ steps.secrets.outputs.SLACK_BOT_TOKEN }}
payload: |
{"text":"Enterprise test failures on ${{ github.ref_name }}","blocks":[{"type":"header","text":{"type":"plain_text","text":":rotating_light: Enterprise test failures :rotating_light:","emoji":true}},{"type":"divider"},{"type":"section","text":{"type":"mrkdwn","text":"test(s) failed on ${{ github.ref_name }}"},"accessory":{"type":"button","text":{"type":"plain_text","text":"View Failing Workflow","emoji":true},"url":"${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}"}}]}
test-summary:
name: Go test failures
runs-on: ubuntu-latest
backport of commit ece2995ee1df24341ec1dd0fdcc2fdedc6737806 (#21731) Co-authored-by: Kuba Wieczorek <kuba.wieczorek@hashicorp.com>
2023-07-10 18:09:52 +00:00
if: |
always() &&
(needs.test-go.result == 'success' ||
needs.test-go.result == 'failure' ||
needs.test-go-fips.result == 'success' ||
needs.test-go-fips.result == 'failure' ||
needs.test-go-race.result == 'success' ||
needs.test-go-race.result == 'failure')
VAULT-17592 Extract failed Go test results across runners (#21625) (#21672) Co-authored-by: Kuba Wieczorek <kuba.wieczorek@hashicorp.com>
2023-07-07 17:52:01 +00:00
needs:
- test-go
- test-go-fips
- test-go-race
steps:
- name: Download failure summary
uses: actions/download-artifact@v3
with:
name: failure-summary
- name: Prepare failure summary
run: |
# We will store the jq query results in a temp file
temp_file_name=temp-$(date +%s)
# The 'jq' command below filters and formats JSON data from input files to generate a failure summary report.
# The query is a bit of a nightmare, though, so let's have a closer look at it.
#
# The command takes input from files matching the pattern "failure-summary-*.json".
# The input files should contain streams of JSON objects(with no commas in between),
# one per line, representing test results.
# Each object should have the "Action" and "Package" keys.
#
# We invoke the command with two flags:
# - '-r' specifies that the output should be in raw format,
# without any JSON formatting. (I.e. no quotes).
# - '-n' tells 'jq' not to read any input from the command line.
# It is used when input is provided through the 'inputs' function or other methods.
#
# 'inputs':
# Read JSON objects from the input files specified after the 'jq' command.
# We assume that the input files contain one JSON object per line.
#
backport of commit ece2995ee1df24341ec1dd0fdcc2fdedc6737806 (#21731) Co-authored-by: Kuba Wieczorek <kuba.wieczorek@hashicorp.com>
2023-07-10 18:09:52 +00:00
# 'select(.Action == "fail")':
VAULT-17592 Extract failed Go test results across runners (#21625) (#21672) Co-authored-by: Kuba Wieczorek <kuba.wieczorek@hashicorp.com>
2023-07-07 17:52:01 +00:00
# Filter JSON array to contain only objects where the value of "Action" is "fail"
#
# The remaining part of the query constructs a formatted string for each filtered JSON object`:
backport of commit ece2995ee1df24341ec1dd0fdcc2fdedc6737806 (#21731) Co-authored-by: Kuba Wieczorek <kuba.wieczorek@hashicorp.com>
2023-07-10 18:09:52 +00:00
# - '\(.Package)' and '\(.Test // "-")' insert the values of the "Package" and "Test" keys into the string,
# respectively. If Test is missing, insert a dash character instead.
VAULT-17592 Extract failed Go test results across runners (#21625) (#21672) Co-authored-by: Kuba Wieczorek <kuba.wieczorek@hashicorp.com>
2023-07-07 17:52:01 +00:00
# - 'input_filename' is a special variable in 'jq' that represents the name of the input file being processed.
# - 'split("-")' splits the input filename on the hyphen ("-") character and returns an array of the
# resulting parts.
# - '.sub(".json"; "")' removes the ".json" extension from the string.
# - The third part of the filename is extracted using '.split("-") | .[2]'.
# - If the fourth part of the filename exists, it contains the test type.
# Otherwise, the default value "normal" is used.
# - The '.sub(".json"; "")' removes the ".json" extension from the string.
#
# The filtered and formatted data is outputted as rows of a Markdown table, like this:
# | pkg1 | test1 | 1 | normal |
# | pkg2 | test2 | 4 | race |
# | pkg3 | test3 | 6 | fips |
backport of commit ece2995ee1df24341ec1dd0fdcc2fdedc6737806 (#21731) Co-authored-by: Kuba Wieczorek <kuba.wieczorek@hashicorp.com>
2023-07-10 18:09:52 +00:00
jq -r -n 'inputs | select(.Action == "fail") | "| \(.Package) | \(.Test // "-") | \(input_filename | split("-") | .[2] | sub(".json"; "")) | \(input_filename | split("-") | .[3] // "normal" | sub(".json";"") )"' failure-summary-*.json | sort >> "$temp_file_name"
VAULT-17592 Extract failed Go test results across runners (#21625) (#21672) Co-authored-by: Kuba Wieczorek <kuba.wieczorek@hashicorp.com>
2023-07-07 17:52:01 +00:00
# if there are test failures, present them in a format of a GH Markdown table
if [ -s "$temp_file_name" ]; then
# shellcheck disable=SC2129
# Here we create the headings for the summary table
echo "### Go test failures" >> "$GITHUB_STEP_SUMMARY"
echo "| Package | Test | Runner Index | Test Type |" >> "$GITHUB_STEP_SUMMARY"
echo "| ------- | ---- | ------------ | --------- |" >> "$GITHUB_STEP_SUMMARY"
cat "$temp_file_name" >> "$GITHUB_STEP_SUMMARY"
else
echo "### All Go tests passed! :white_check_mark:" >> "$GITHUB_STEP_SUMMARY"
[QT-589] Use the go module cache between CI and build (#21764) (#21790) In order to reliably store Go test times in the Github Actions cache we need to reduce our cache thrashing by not using more than 10gb over all of our caches. This change reduces our cache usage significantly by sharing Go module cache between our Go CI workflows and our build workflows. We lose our per-builder cache which will result in a bit of performance hit, but we'll enable better automatic rebalancing of our CI workflows. Overall we should see a per branch reduction in cache sizes from ~17gb to ~850mb. Some preliminary investigation into this new strategy: Prior build workflow strategy on a cache miss: Download modules: ~20s Build Vault: ~40s Upload cache: ~30s Total: ~1m30s Prior build workflow strategy on a cache hit: Download and decompress modules and build cache: ~12s Build Vault: ~15s Total: ~28s New build workflow strategy on a cache miss: Download modules: ~20 Build Vault: ~40s Upload cache: ~6s Total: ~1m6s New build workflow strategy on a cache hit: Download and decompress modules: ~3s Build Vault: ~40s Total: ~43s Expected time if we used no Go caching: Download modules: ~20 Build Vault: ~40s Total: ~1m Signed-off-by: Ryan Cragun <me@ryan.ec> Co-authored-by: Ryan Cragun <me@ryan.ec>
2023-07-12 19:26:00 +00:00
fi
Reference in a new issue Copy permalink