fleet/.github/workflows
Lucas Manuel Rodriguez f9d6cf986b
Fix expected number of hosts in fleetctl-preview-latest workflow (#13329)
#13182

[This PR](https://github.com/fleetdm/osquery-in-a-box/pull/18) in the
osquery-in-a-box repository recently added a new host to the simulated
host list which broke the CI job in the fleetdm/fleet repository.

PR run with this branch:
https://github.com/fleetdm/fleet/actions/runs/5866786432

PS: One of the reasons we had this osquery-in-a-box repository outside
the monorepo was to not break customers using `fleetctl preview`. But
now that we have Fleet Sandbox and we don't encourage users to use
`fleetctl preview`:
1. Does it  make sense to have the separate repository?
2. Does it make sense to continue supporting this workflow in CI?
2023-08-15 14:16:07 -03:00
..
config set default shell in workflows (#8108) 2022-10-07 09:43:56 -06:00
build-and-push-fleetctl-docker.yml upgrade Go version to 1.19.11 (#12902) 2023-07-26 11:09:22 -07:00
build-binaries.yaml upgrade Go version to 1.19.11 (#12902) 2023-07-26 11:09:22 -07:00
build-orbit.yaml upgrade Go version to 1.19.11 (#12902) 2023-07-26 11:09:22 -07:00
codeql-analysis.yml Bump github/codeql-action from 2.2.4 to 2.20.1 (#12437) 2023-06-23 12:40:54 -07:00
deploy-fleet-website.yml Change Node version used in Github workflows, add build-storybook step to website test (#12748) 2023-07-13 13:11:20 -05:00
docs.yml add concurrency to ci (#8271) 2022-10-24 14:01:00 -06:00
dogfood-deploy.yml Warn against deploying fleetdm/fleet:main directly (#11316) 2023-04-25 13:22:59 -05:00
example-workflow.yaml Add example workflow (#11893) 2023-05-23 13:52:21 -05:00
fleet-and-orbit.yml upgrade Go version to 1.19.11 (#12902) 2023-07-26 11:09:22 -07:00
fleetctl-preview-latest.yml Fix expected number of hosts in fleetctl-preview-latest workflow (#13329) 2023-08-15 14:16:07 -03:00
fleetctl-preview.yml Bump actions/upload-artifact from 3.1.0 to 3.1.2 (#10183) 2023-04-24 11:27:56 -07:00
fleetctl-workstations-canary.yml Update action version (#13136) 2023-08-03 14:27:32 -07:00
fleetctl-workstations.yml Update action version (#13136) 2023-08-03 14:27:32 -07:00
generate-desktop-targets.yml upgrade Go version to 1.19.11 (#12902) 2023-07-26 11:09:22 -07:00
generate-nudge-targets.yml Bump actions/upload-artifact from 3.1.0 to 3.1.2 (#10183) 2023-04-24 11:27:56 -07:00
generate-osqueryd-targets.yml Generate targets for osquery 5.9.1 (#12410) 2023-06-21 23:14:52 -07:00
golangci-lint.yml upgrade Go version to 1.19.11 (#12902) 2023-07-26 11:09:22 -07:00
goreleaser-fleet.yaml Bump actions/setup-go from 2.1.3 to 4.0.1 (#12294) 2023-06-23 12:38:42 -07:00
goreleaser-orbit.yaml Bump actions/setup-go from 2.1.3 to 4.0.1 (#12294) 2023-06-23 12:38:42 -07:00
goreleaser-snapshot-fleet.yaml upgrade Go version to 1.19.11 (#12902) 2023-07-26 11:09:22 -07:00
integration.yml upgrade Go version to 1.19.11 (#12902) 2023-07-26 11:09:22 -07:00
pr-helm.yaml add concurrency to ci (#8271) 2022-10-24 14:01:00 -06:00
push-osquery-perf-to-ecr.yml Bump aws-actions/amazon-ecr-login from 1.5.3 to 1.6.0 (#11514) 2023-05-03 12:06:24 -07:00
README.md add concurrency to ci (#8271) 2022-10-24 14:01:00 -06:00
release-helm.yaml Use actions token during helm-publish workflow (#12430) 2023-06-21 09:30:25 -06:00
scorecards-analysis.yml Bump github/codeql-action from 2.2.4 to 2.20.1 (#12437) 2023-06-23 12:40:54 -07:00
test-db-changes.yml upgrade Go version to 1.19.11 (#12902) 2023-07-26 11:09:22 -07:00
test-go.yaml upgrade Go version to 1.19.11 (#12902) 2023-07-26 11:09:22 -07:00
test-native-tooling-packaging.yml upgrade Go version to 1.19.11 (#12902) 2023-07-26 11:09:22 -07:00
test-packaging.yml upgrade Go version to 1.19.11 (#12902) 2023-07-26 11:09:22 -07:00
test-website.yml Change Node version used in Github workflows, add build-storybook step to website test (#12748) 2023-07-13 13:11:20 -05:00
test-yml-specs.yml upgrade Go version to 1.19.11 (#12902) 2023-07-26 11:09:22 -07:00
test.yml generate js coverage report in CI (#12029) 2023-06-01 17:46:25 +01:00
tfsec.yml Bump github/codeql-action from 2.2.4 to 2.20.1 (#12437) 2023-06-23 12:40:54 -07:00
tfvalidate.yml Upversion github actions in tfvalidate.yml (#12005) 2023-05-28 22:54:46 -04:00
trivy_scan.yml Bump github/codeql-action from 2.2.4 to 2.20.1 (#12437) 2023-06-23 12:40:54 -07:00
update-certs.yml add concurrency to ci (#8271) 2022-10-24 14:01:00 -06:00

Github Actions

Fleet uses Github Actions for continuous integration (CI). This document describes best practices and at patterns for writing and maintaining Fleet's Github Actions workflows.

Bash

By default, Github Actions sets the shell to bash -e for linux and MacOS runners. To help write safer bash scripts in run jobs and avoid common issues, override the default by adding the following to the workflow file

defaults:
  run:
    # fail-fast using bash -eo pipefail. See https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#exit-codes-and-error-action-preference
    shell: bash

By specifying the default shell to bash, some extra flags are set. The option pipefail changes the behaviour when using the pipe | operator such that if any command in a pipeline fails, that commands return code will be used a the return code for the whole pipeline. Consider the following example in test-go.yaml

    - name: Run Go Tests
      run: |
        # omitted ...
          make test-go 2>&1 | tee /tmp/gotest.log

If the pipefail option was not set, this job would always succeed because tee would always return success. This is not the intended behavior. Instead, we want the job to fail if make test-go fails.

Concurrency

Github Action runners are limited. If a lot of workflows are queued, they will wait in pending until a runner becomes available. This has caused issue in the past where workflows take an excessively long time to start. To help with this issue, use the following in workflows

# This allows a subsequently queued workflow run to interrupt previous runs
concurrency:
  group: ${{ github.workflow }}-${{ github.head_ref || github.run_id}}
  cancel-in-progress: true

When a workflow is triggered via a pull request, it will cancel previous running workflows for that pull request. This is especially useful when changes are pushed to a pull request frequently. Manually triggered workflows, workflows that run on a schedule, and workflows triggered by pushes to main are unaffected.