* Run shellcheck for all shell scripts in repository
Update the shellcheck command in static_checks.yml to not only scan the
contents of ./bin, but search for all files with mimetype
text/x-shellscript and feed them to shellcheck.
Certainly, this is a tad more time consuming than just scanning one
directory, but still a quite fast thing to do while it prevents any
new scripts to fly under the radar.
(Also, there is no need to exclude *.nuspec or *.ps1 from the find
command as they do not have the text/x-shellscript mimetype.)
Change-Id: I7433d231e8a315df65c03ee8765914e782057343
Signed-off-by: Joakim Roubert <joakimr@axis.com>
* Updates after review comment
Move shellcheck of all scripts to own script that is then called by
static_checks.yml as suggested by @kleimkuhler.
Also updated sources for helm-build and kind-load so that the
new shellcheck-all script can be called from any directory.
Change-Id: I9e82230459cb843c4143ec979c93060f424baed8
Signed-off-by: Joakim Roubert <joakim.roubert@axis.com>
* Bump KinD to 0.8.1
This brings us K8s 1.18, which is in theory passing all the integration
tests. Currently the tracing one is failing just because of the quay.io
downtime, that hosts the nginx-ingress image.
Re #4382
Delete variable `os` that is not used. The golangci-lint downloader script does its own extensive platform lookup before downloading the selected binary.
Signed-off-by: Joakim Roubert <joakimr@axis.com>
## Motivation
linkerd/rfc#22
## Solution
Use the [markdown-lint-action](https://github.com/marketplace/actions/markdown-linting-action) to lint all `.md` files for all pull requests
and pushes to master.
This action uses the default rules outlined in [markdownlint
package](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md).
The additional rules are added are explained below:
- Ignore line length lints for code blocks
- Ignore line length lints for tables
- Allow duplicate sub-headers in sibling headers (e.g. allowing multiple ##
Significant headers in `CHANGES.md` as long as they are part of separate
release headers)
Signed-off-by: Kevin Leimkuhler <kevin@kleimkuhler.com>
Pass grep output through xargs.
Use `${0%/*}` instead of `$bindir `since the variable `bindir` exists in
_tag.sh too and then triggers the shellcheck variable modifed warning.
Script uses no bash features and can thus be a POSIX /bin/sh script.
Signed-off-by: Joakim Roubert <joakimr@axis.com>
shellcheck will not accept the string DO since it is not sure whether it is a misspelled do command or a string with DO. Explicitly quoting it will mitigate this.
Signed-off-by: Joakim Roubert <joakimr@axis.com>
The SC1090 "Can't follow non-constant source" issue is addressed in the way suggested in shellcheck's documentation; the source paths are pointed out in shellcheck comments. By adding the bin dir to the -P shellcheck CLI parameter, we avoid having to state the bin directory in each and every script file.
Signed-off-by: Joakim Roubert <joakimr@axis.com>
Remove superfluous echo commands in assignments.
Add quotes.
Simplify the for loops that shellcheck didn't like.
Signed-off-by: Joakim Roubert <joakimr@axis.com>
Followup to #4341
Replaced all the `t.Error`/`t.Fatal` calls in the integration tests with the
new functions defined in `testutil/annotations.go` as described in #4292,
in order for the errors to produce Github annotations.
This piece takes care of the CNI integration test suite.
This also enables the annotations for these and the general integration
tests, by setting the `GH_ANNOTATIONS` environment variable in the
workflows whose flakiness we're interested on catching: Kind
integration, Cloud integration and Release.
Re #4176
Use [gotestsum](https://github.com/gotestyourself/gotestsum) for running
unit tests in CI, so we get a summary result at the end, instead of having to
scroll up to find failures.
Doesn't apply for integration tests, as only failures are shown there,
and they're easily visible.
* Add Linkerd CLI Chocolatey Package
This PR partially fixes#3063 by building a chocolatey package for Linkerd2's Windows CLI
It adds the build scripts for the Linkerd chocolatey package and based on discussions in
https://github.com/linkerd/linkerd2/pull/3921
Signed-off-by: Animesh Narayan Dangwal <animesh.leo@gmail.com>
Second part of #4176
Added extra Jest reporter when running js tests from CI, which will send
to stdout a GH annotation for each test failure, something like:
```
::error file=/home/alpeb/src/forks/linkerd2/web/app/js/components/Navigation.test.jsx::Navigation › checks state when versions do not match
```
See the [health
metrics RFC](https://github.com/linkerd/rfc/blob/master/design/0002-ci-health-metrics.md) for more context.
* Bug in `linkerd uninstall` when attempting to delete PSP
We were using a wrong apiVersion for PSP in `linkerd uninstall`'s
output, which avoids removing that resource:
```
$ linkerd uninstall | kubectl delete -f -
clusterrole.rbac.authorization.k8s.io "linkerd-linkerd-controller"
deleted
clusterrole.rbac.authorization.k8s.io "linkerd-linkerd-destination"
deleted
...
mutatingwebhookconfiguration.admissionregistration.k8s.io
"linkerd-proxy-injector-webhook-config" deleted
validatingwebhookconfiguration.admissionregistration.k8s.io
"linkerd-sp-validator-webhook-config" deleted
namespace "linkerd" deleted
error: unable to recognize "uninstall.yml": no matches for kind
"PodSecurityPolicy" in version "extensions/v1beta1"
$ kubectl get psp -oname
podsecuritypolicy.policy/linkerd-linkerd-control-plane
```
I've also replaced the uninstall integration test with a new separate
suite that performs the installation, waits for it to be ready,
uninstalls, and then confirms `linkerd check --pre` returns as expected.
The `cloud_integration_tests` job was creating its tests under
namespaces containing the git SHA. This is a left-over from when all the
tests ran in the same cluster, which is no longer the case, and thus no
longer needed.
This fixes the [current CI
failure](https://github.com/linkerd/linkerd2/runs/556330879?check_suite_focus=true#step:6:24)
in master.
* Fix bin/kind-load for pull requests
Followup to #4212
External PRs were failing because:
1) The image tarballs weren't being loaded from the `images-archives`
directory
2) Concurrent calls to `bin/kind` were attempting to download the KinD
binary simultaneously, resulting in a "text file busy" error. To avoid
that, now we just call `bin/kind` synchronously one time beforehand.
Fixes#4206 Followup to #4167
Extract common logic to load images into KinD, from `bin/kind-load`, `bin/install-pr`, `.github/workflows/kind_integration.yml` and `.github/workflows/release.yml`.
Besides removing the duplication, `bin/kind-load` will benefit in performance by having each image be loaded in parallel.
```
Load into KinD the images for Linkerd's proxy, controller, web, grafana, debug and cni-plugin.
Usage:
bin/kind-load [--images] [--images-host ssh://linkerd-docker]
Examples:
# Load images from the local docker instance
bin/kind-load
# Load images from tar files located in the current directory
bin/kind-load --images
# Retrieve images from a remote docker instance and then load them into KinD
bin/kind-load --images --images-host ssh://linkerd-docker
Available Commands:
--images: use 'kind load image-archive' to load the images from local .tar files in the current directory.
--images-host: the argument to this option is used as the remote docker instance from which images are first retrieved
(using 'docker save') to be then loaded into KinD. This command requires --images.
```
## Motivation
#4147 adds a script for setting up a local cluster that uses the images built
from the changes introduced in a forked PR. This would be useful for all PRs.
In order to install Linkerd from a PR into a local cluster, the images still
need to be built at some point. If you happen to have SSH config setup for our
Packet host, you can pull them from there. That is not very
accessible--requiring that someone adds you as a user--so we can take a
similar approach to forked PRs.
## Solution
All PRs now make an artifact directory that is uploaded as part of the KinD
integration tests. This way, the `install-pr` script can use those images no
matter if the PR is a fork or not.
Extracted the logic to pull the latest release notes, out of
`bin/create-release-tag` into `bin/_release.sh` so that it can be reused
in the `release.yml` workflow, which needs to use that inside
`gh_release` when creating the github release in order to have prettier
markup release notes instead of a plaintext message pulled out of the tag
message.
The new extracted function also receives an optional argument with the
name of the file to put the release notes into, because the `body_path`
parameter in `softprops/action-gh-release` doesn't work with dynamic
vars.
Finally, now the `website_publish` job will only launch until the `gh_release`
has succeeded.
PR #4117 was root-caused with the help of `shellcheck`.
This change introduces a `bin/shellcheck` script, and adds it to CI. In
CI, many checks are disabled to allow it to pass. This will at least
prevent introduction of new classes of shell issue, and should motivate
re-enabling more checks over time.
Signed-off-by: Andrew Seigner <siggy@buoyant.io>
When adding an action we can quickly vet it and fix it to a sha. Whereas
if we use a tag, the 3rd party can change the code and retag it without us noticing
Added the `website_publish_check` job, triggered upon edge/stable tag pushes,
that verifies that the install script at the website has indeed been
updated with the corresponding edge/stable version. It performs the
check every 5 seconds, 10 times, before giving up and failing the build
run. Tested fine in my fork 👍
## Motivation
A goal of the release automation project is to automate the website publish
that publishes a new install script that uses the new release version.
linkerd/website#668 removed the hard coded versions from the repo and moved
the version update into the `make publish` command.
That workflow now needs to be triggered by a release in `linkerd2`.
## Solution
Once `kind_integration_tests` and `cloud_integration_test` pass, a job runs
using the [repository-dispatch](https://github.com/marketplace/actions/repository-dispatch) action to create a repository dispatch event in
`linkerd/website`.
This dispatch event will (current PR: linkerd/website#670) trigger the
publish workflow.
## Testing
Tested in my fork [here](https://github.com/kleimkuhler/linkerd2/actions/runs/45165789)
## Additional steps needed
A new `RELEASE_TOKEN` secret needs to be added to this repo. It should be the
personal access token of [l5d-bot](https://github.com/l5d-bot) with `repo` access.
Signed-off-by: Kevin Leimkuhler <kevin@kleimkuhler.com>
* New CI job to automatically generate the Github release
Fixes#4083
New `gh_release` job in the `release.yml` for creating the release in
Github and uploading the CLI binaries for each platform, along with
their checksum files.
This job only gets triggered upon successful docker images building and
pushing, and kind and cloud integration tests passing.
The Helm chart deploying job gets now triggered upon the success of this
new job.
Signed-off-by: Alejandro Pedraza <alejandro@buoyant.io>
Fixes#4082
This tested fine in a fork, under various scenarios combining:
- Modify markup file in root dir
- Modify markup file in subdir
- Modify non-markup file
- In master
- In a PR
## Motivation
A release workflow will be the only triggered workflow on `push.tags` events.
As a first step in automating the release process, it should assert that
integration tests pass once the docker images have been tagged.
Both KinD and cloud integration tests should run since they have different
sets of integration tests that they are responsible for running.
It then needs to run the `chart_deploy` job.
## Testing
This has been fully tested with a release tag push on my fork. The run can be
found [here](https://github.com/kleimkuhler/linkerd2/actions/runs/42664128)
It properly failed on `chart_deploy` because I did not want to push a test tag
helm chart.
## Solution
This workflow will:
- Build the docker images on the Packet Host
- Tag the docker images with the release tag
- Run KinD integration tests
- Run cloud integration tests
- Run `chart_deploy`
Signed-off-by: Kevin Leimkuhler <kevin@kleimkuhler.com>
Depends on #4033
## Motivation
If any job fails in the current GH Actions workflow, a re-run on the same
commit SHA requires re-running *all* jobs--regardless if the job already
passed in the previous run.
This can be problematic when dealing with flakiness in the integration tests.
If a test fails due to flakiness in `cloud_integration_tests`, all the unit
tests, static checks, and `kind_integration_tests` are re-run which leads to
lots of waiting and dealing with the possibility of flakiness in earlier jobs.
With this change, individual workflows can now be re-run without triggering
all other jobs to complete again first.
## Solution
`workflow.yml` is now split into:
- `static_checks.yml`
- `unit_tests.yml`
- `kind_integration.yml`
- `cloud_integration.yml`
### Workflows
`statc_checks.yml` performs checks related to dependencies, linting, and
formatting.
`unit_tests.yml` performs the Go and JS unit tests.
`kind_integration.yml` builds the images (on Packet or the GH Action VM) and
runs the integration tests on a KinD cluster. This workflow continues to run
for **all** PRs and pushes to `master` and tags.
`cloud_integration.yml` builds the images only on Packet. This is because
forked repositories do not need to trigger this workflow. It then creates a
unique GKE cluster and runs the integration tests on the cluster.
### The actual flow of work..
A forked repository or non-forked repository opening a PR triggers:
- `static_checks`
- `unit_tests`
- `kind_integration_tests`
These workflows all run in parallel and are invidivually re-runnable.
A push to `master` or tags triggers:
- `static_checks`
- `unit_tests`
- `kind_integration_tests`
- `cloud_integration_tests`
These workflows also all run in parallel, including the `docker_build` step of
both integration test workflows. This has not conflicted in testing as it
takes place on the same Packet host and just utilizes docker layer caching
well.
Signed-off-by: Kevin Leimkuhler <kevin@kleimkuhler.com>
Run all PRs on GH Actions VMs
## Motivation
Currently all pushes to master branch, tags, and Linkerd org member PRs run
the `kind_integration_host` job on the same Packet host.
The means that parallel jobs spin up KinD clusters with a unique name and
sandbox the tests so that they do not clash.
This is problematic for a few reasons:
* There is a limit on the number of jobs we can run in parallel due to
resource constraints.
* Workflow cancellation and re-runs conflict when the cancelled run deletes
it's namespaces and the running one expects them to be present.
* There has been an observed flakiness with running multiple KinD clusters
resulting in inconsistent timeouts and docker errors.
## Solution
This change moves all KinD integration testing to GH Actions VMs. This is
currently what forked repository workflows do.
There is no longer a `docker_pull` job as it's responsibilities has been moved
into one of the `kind_integration_tests` steps.
The renamed `kind_integration_tests` job is responsible for **all** PR
workflows and has steps specific to forked and non-forked repositories.
### Non-forked repository PRs
The Packet host is still used for building docker images as leveraging docker
layer caching is still valuable--a build can be as fast as 30 seconds compared
to ~12 minutes.
Loading the docker images into the KinD cluster on the GH Action VM is done by
saving the Packet host docker images as image archives, and loading those
directly into the local KinD cluster.
### Forked repository PRs
`docker_build` has been sped up slightly by sending `docker save` processes to
the background.
Docker layer caching cannot be leveraged since there are no SSH secrets
available, so the `artifact-upload`/`artifact-download` actions introduced in
#TODO are still used.
### Cleanup
This PR also includes some general cleanup such as:
* Some job names have been renamed to better reflect their purpose or match
the current naming pattern.
* Environment variables are set earlier in jobs as a separate step if it is
currently exported multiple times.
* Indentation was really bothering me because it switches back and forth
throughout the workflow file, so lists are now indented.
Signed-off-by: Kevin Leimkuhler <kevin@kleimkuhler.com>
* Allow CI to run concurrent builds in master
Fixes#3911
Refactors the `cloud_integration` test to run in separate GKE clusters
that are created and torn down on the fly.
It leverages a new "gcloud" github action that is also used to set up
gcloud in other build steps (`docker_deploy` and `chart_deploy`).
The action also generates unique names for those clusters, based on the
git commit SHA and `run_id`, a recently introduced variable that is
unique per CI run and available to all the jobs.
This fixes part of #3635 in that CI runs on the same SHA don't interfere
with one another (in the `cloud_integration` test; still to do for
`kind_integration`).
The "gcloud" GH action is hosted under its own repo in https://github.com/linkerd/linkerd2-action-gcloud
* Allow CI to run concurrent builds in master
Fixes#3911
Refactors the `cloud_integration` test to run in separate GKE clusters
that are created and torn down on the fly.
It leverages a new "gcloud" github action that is also used to set up
gcloud in other build steps (`docker_deploy` and `chart_deploy`).
The action also generates unique names for those clusters, based on the
git commit SHA and `run_id`, a recently introduced variable that is
unique per CI run and available to all the jobs.
This fixes part of #3635 in that CI runs on the same SHA don't interfere
with one another (in the `cloud_integration` test; still to do for
`kind_integration`).
The "gcloud" GH action is supported by `.github/actions/gcloud/index.js`
that has a couple of dependencies. To avoid having to commit
`node_modules`, after every change to that file one must run
```bash
# only needed the first time
npm i -g @zeit/ncc
cd .github/actions/gcloud
ncc build index.js
```
which generates the self-contained file
`.github/actions/gcloud/dist/index.js`.
(This last part might get easier in the future after other refactorings
outside this PR).
* Run integration tests for forked repos
Signed-off-by: Kevin Leimkuhler <kevin@kleimkuhler.com>
* Address reviews
Signed-off-by: Kevin Leimkuhler <kevin@kleimkuhler.com>
* Address more reviews
Signed-off-by: Kevin Leimkuhler <kevin@kleimkuhler.com>
* Move some conditionals to jobs
Signed-off-by: Kevin Leimkuhler <kevin@kleimkuhler.com>
* Change job name
Signed-off-by: Kevin Leimkuhler <kevin@kleimkuhler.com>
* Move more conditionals to job level
Signed-off-by: Kevin Leimkuhler <kevin@kleimkuhler.com>
* Added more flags to 'gcloud container clusters create' and consolidated
'create' and 'destroy' into ' action'
* Run kind cleanup only for non-forked PRs
Signed-off-by: Kevin Leimkuhler <kevin@kleimkuhler.com>
* Got rid of cloud_cleanup by using a post hook in the gcloud action
* Removed cluster naming responsibility from the gcloud action
* Consolidate .gitignore statements
* Removed bin/_gcp.sh
* Change name of Kind int. test job
Signed-off-by: Kevin Leimkuhler <kevin@kleimkuhler.com>
* Ensure `kind_cleanup` still runs on cancelled host CI runs
Signed-off-by: Kevin Leimkuhler <kevin@kleimkuhler.com>
* Add reviews
Signed-off-by: Kevin Leimkuhler <kevin@kleimkuhler.com>
* Update workflow comment
Signed-off-by: Kevin Leimkuhler <kevin@kleimkuhler.com>
* Split index.js into setup.js and destroy.js
* trigger build
* Moved the gcloud action into its own repo
* Full version for the gcloud GH action
* Rebase back to master
Signed-off-by: Kevin Leimkuhler <kevin@kleimkuhler.com>
* Remvoe additional changes
Signed-off-by: Kevin Leimkuhler <kevin@kleimkuhler.com>
* Remove additional changes
Signed-off-by: Kevin Leimkuhler <kevin@kleimkuhler.com>
* Trigger CI
Signed-off-by: Kevin Leimkuhler <kevin@kleimkuhler.com>
Co-authored-by: Alejandro Pedraza <alejandro.pedraza@gmail.com>
In light of the breaking changes we are introducing to the Helm chart and the convoluted upgrade process (see linkerd/website#647) an integration test can be quite helpful. This simply installs latest stable through helm install and then upgrades to the current head of the branch.
Signed-off-by: Zahari Dichev zaharidichev@gmail.com
## edge-20.1.3
* CLI
* Introduced `linkerd check --pre --linkerd-cni-enabled`, used when the CNI
plugin is used, to check it has been properly installed before proceeding
with the control plane installation
* Added support for the `--as-group` flag so that users can impersonate
groups for Kubernetes operations (thanks @mayankshah160!)
* Controller
* Fixed an issue where an override of the Docker registry was not being
applied to debug containers (thanks @javaducky!)
* Added check for the Subject Alternate Name attributes to the API server
when access restrictions have been enabled (thanks @javaducky!)
* Added support for arbitrary pod labels so that users can leverage the
Linkerd provided Prometheus instance to scrape for their own labels
(thanks @daxmc99!)
* Fixed an issue with CNI config parsing
Signed-off-by: Kevin Leimkuhler <kevin@kleimkuhler.com>
* Revert "Replace actions/checkout with actions/upload/download (#3602)"
This reverts commit 397970e917.
* Upgraded actions/checkout to @v2
Reverts #3602 and Fixes#3881
* Use `kind export kubeconfig` instead of `scp`
Followup to #3864
[comment](https://github.com/linkerd/linkerd2/pull/3864#discussion_r360976473)
Stop moving the kubeconfig file between the Github Action env and the
build server with `scp` and use instead `kind export kubeconfig`.
* Replaced deprecated '--loglevel debug' flag with '--verbosity 3'
* Upgrade `kind` to v0.6.1
Fixes#3852
Upgraded `/bin/kind` to pull v0.6.1.
Also have `workflow.yml` use `KUBECONFIG` explicitly for setting the
location of the config file, now that `kind get kubeconfig-path` has
been deprecated (check
https://github.com/kubernetes-sigs/kind/releases/tag/v0.6.0 for detailed
info).
Note that in the build server the kind binary for this version is
`kind-0.6.1`, leaving the `kind` binary still pointing to v0.5.1 while
this gets merged and all the PR branches get this.
* Enable mixed configuration of skip-[inbound|outbound]-ports using port numbers and ranges (#3752)
* included tests for generated output given proxy-ignore configuration options
* renamed "validate" method to "parseAndValidate" given mutation
* updated documentation to denote inclusiveness of ranges
* Updates for expansion of ignored inbound and outbound port ranges to be handled by the proxy-init rather than CLI (#3766)
This change maintains the configured ports and ranges as strings rather than unsigned integers, while still providing validation at the command layer.
* Bump versions for proxy-init to v1.3.0
Signed-off-by: Paul Balogh <javaducky@gmail.com>
This PR addresses recent JS unit test failures on CI by:
* Upgrading yarn from 1.7.0 to 1.21.1 (current stable version) in the Dockerfile
and Github Actions workflow
* Wrapping the yarn installation with the --network-concurrency 1 flag, setting the
maximum number of concurrent network requests to 1, suggested as a fix here:
https://github.com/yarnpkg/yarn/issues/2629
Follow up from #3730, GitHub Actions was failing in the following ways:
- booting 5 parallel kind clusters in the matrix job was overloading the
Docker host
- `~/.ssh/known_hosts` file was empty following gcloud sdk installation
Four changes to mitigate these issues:
- generate `known_hosts` from a secret, rather than an `ssh-keyscan`
command
- generate `~/.ssh/config` from a secret
- set `max-parallel: 3` on the matrix job
- install gcloud sdk prior to Docker ssh setup
TODO:
- remove `DOCKER_ADDRESS`, `DOCKER_HOST_PRIVATE_KEY`
Signed-off-by: Andrew Seigner <siggy@buoyant.io>
Fixes#3566
As explained in #3566, as of go 1.13 there's a strict check that ensures a dependency's timestamp matches it's sha (as declared in go.mod). Our smi-sdk dependency has a problem with that that got resolved later on, but more work would be required to upgrade that dependency. In the meantime a quick pair of replace statements at the bottom of go.mod fix the issue.
* Keep old releases in Helm repo index
When building the Helm repo index file, keep the references to the old
releases. Also rename and keep the old index file in case
something goes wrong when generating the new one.
Fixes#3561
CI currently enforcing formatting rules by using the fmt linter of golang-ci-lint which is invoked from the bin/lint script. However it doesn't seem possible to use golang-ci-lint as a formatter, only as a linter which checks formatting. This means any formatter used by your IDE or invoked manually may or may not use the same formatting rules as golang-ci-lint depending on which formatter you use and which specific revision of that formatter you use.
In this change we stop using golang-ci-lint for format checking. We introduce `tools.go` and add goimports to the `go.mod` and `go.sum` files. This allows everyone to easily get the same revision of goimports by running `go install -mod=readonly golang.org/x/tools/cmd/goimports` from inside of the project. We add a step in the CI workflow that uses goimports via the `bin/fmt` script to check formatting.
Some shell gymnastics were required in the `bin/fmt` script to work around some limitations of `goimports`:
* goimports does not have a built-in mechanism for excluding directories, and we need to exclude the vendor director as well as the generated Go sources
* goimports returns a 0 exit code, even when formatting errors are detected
Signed-off-by: Alex Leong <alex@buoyant.io>
* Have CI push the Helm artifacts into GCS
- Added missing OWNERS and README files
- Added maintainers section to Chart.yaml
- Changed NOTES.txt so it points to the installation of the CLI
- Set the proxy-init version to v1.1.0 in values.yaml
Ref #3256
Signed-off-by: Alejandro Pedraza <alejandro@buoyant.io>
The repo depended on an old version of client-go. It also depended on
stern, which itself depended on an old version of client-go, making
client-go upgrade non-trivial.
Update the repo to client-go v12.0.0, and also replace stern with a
fork.
This fork of stern includes the following changes:
- updated to use Go Modules
- updated to use client-go v12.0.0
- fixed log line interleaving:
- https://github.com/wercker/stern/issues/96
- based on:
- 8723308e46Fixes#3382
Signed-off-by: Andrew Seigner <siggy@buoyant.io>
The kind clusters booted by the integration tests each had to pull
Prometheus and proxy-init images from the internet during linkerd
install.
Preemptively pull the images from the internet once, then execute `kind
load` commands for each of the clusters prior to starting integration
tests.
Depends on #3397
Signed-off-by: Andrew Seigner <siggy@buoyant.io>
GitHub Actions has been running unit and integration tests, in parallel
with Travis running those same tests, and also handling master merges
and tags.
This change completes the transtion to GitHub Actions, removing all
references to Travis. Similar to Travis, GitHub Actions now acts on
master merges and tag pushes by pushing Docker images to gcr.io, and
running integration tests against a GKE cluster.
Signed-off-by: Andrew Seigner <siggy@buoyant.io>
GitHub Action secrets are intentionally not available to forked PRs.
This causes the integration tests that require those secrets to fail.
Modify GitHub Actions such that they only run for non-forked PRs.
Signed-off-by: Andrew Seigner <siggy@buoyant.io>
The existing Travis CI setup requires additional integrations and
permissions with Github, and also lacks some flexibility around job
dependency management.
Introduce a new CI workflow based on Github Actions. This initial
workflow performs the same CI work that Travis does, and will iniitially
run in parallel:
- Go unit tests
- JS unit tests
- Go lint
- Validate Go deps
- Integration tests (deep, upgrade, helm)
Signed-off-by: Andrew Seigner <siggy@buoyant.io>