Previously we had some required configuration for the Github Actions,
and forks of OPA would need to set them _and_ have the underlying
infra configured (eg, docker registries, s3 bucket, etc).
Now it will check if the secrets are set, and if any required ones
are missing it will skip the steps.
This significantly lowers the bar for OPA forks to be able to run the
normal action workflows without getting errors. The only lost
functionality is primarily around publishing release assets, which
is not required for dev forks, and other forks can opt int to pieces
they care about (eg, only want to publish docker images and no
s3 release assets).
Signed-off-by: Patrick East <east.patrick@gmail.com>
We previously supported overriding via an environment variable, but
this meant for anyone who wanted to run their own telemetry endpoint
they would _always_ have to specify it while running their OPA's.
This change allows for someone to build OPA and encode the custom
url as the default. Ex:
```
make build TELEMETRY_URL=http://localhost:9876/custom/
```
Signed-off-by: Patrick East <east.patrick@gmail.com>
Update the conditional syntax to be valid and switch to a different
slack action helper that provides a better end result.
Signed-off-by: Patrick East <east.patrick@gmail.com>
We are using a 3rd party action to simplify this. It appears to be
relatively well used, and the code looked pretty safe. It only has
access to the slack webhook secret, which is itself restricted in
permissions, so the risk is minimal.
It is configured to post a message for jobs that fail to the OPA
slack in the #development channel.
Signed-off-by: Patrick East <east.patrick@gmail.com>
This adds the tooling from:
https://github.com/tsandall/fuzz-opa
plus some new helper scripts and make targets to use it as a pass/fail
CI step.
The script will (as of now) run the fuzzing for an hour and raise an
error if any crashers were found. We can adjust the timing as needed,
this initial setting is pretty arbitrary.
Signed-off-by: Patrick East <east.patrick@gmail.com>
We will run the golang race detector nightly (to start with.. we'll
adjust the workflow as needed).
One thing to note is that currently cgo is required for the race
detector, so we have to enable it when running this make target.
Fixes: #2388
Signed-off-by: Patrick East <east.patrick@gmail.com>
We were only doing it on the PR workflows, but we should have one
uploaded on master after merges to keep an up to date baseline.
Signed-off-by: Patrick East <east.patrick@gmail.com>
This includes some refactors to the build steps. High level items:
* Add variables for DOCKER_IMAGE, S3_RELEASE_BUCKET to allow for forks
of OPA to re-use the GitHub actions with their own s3 buckets and
docker orgs/image names.
* Unify the release build steps to use `make release` and the binaries
being located under `_release/$(VERSION)`. All CI targets now rely
on binaries being in that `RELEASE_DIR`, including image building
steps The `make build` target is unaffected.
* Add a wrapper to allow the CI to run the various golang target
stages separately, but sharing the same docker configuration.
* Conditionally specify `-it` for docker run commands based on whether
A tty is available.
* Added scripts to automate drafting a release with binary assets vi
the `hub` CLI.
* The release process triggered on a tag being pushed will now use the
same binaries from `make release` for the docker images as well as
the ones attached to the release (which are available under
https://openpolicyagent.org/downloads/).
The actions themselves are split into 3 workflows:
pull-request.yaml:
Triggers on pull requests. This will run all the normal tests/checks
as before on Travis, however they are now split into separate jobs.
In addition to what was done on Travis we will now have Codecov
results included.
post-merge.yaml:
Triggers after a change is pushed to master. This will run tests and
build+publish the `edge` and `dev` artifacts to dockerhub and s3.
post-tag.yaml:
Triggers after a tag has been pushed. Similar to post-merge.yaml it
will run tests and build+publish release artifacts (for the tagged
version). It will also create a draft release on GitHub with the
same artifacts and notes from the CHANGELOG.md. If a release already
exists it will be updated to include the assets, however the release
notes will _not_ be added.
The RELEASE.md steps have been updated and include notes on the new
steps.
Signed-off-by: Patrick East <east.patrick@gmail.com>
Patrick East