If we have multiple builds to master that intend to deploy AUR packages or documentation, we must ensure that the jobs are locked and executed sequentially, not simultaneously. If they were to run simultaneously this has the ability to cause a race condition when attempting to commit the respective steps.
* [CI] Lint all builds except tagged commits to satisfy branch protection
* [CI] Add automatic retries for linting failures
This is to treat any issues with the reviewdog API server and occasional failures we are seeing.
* [FEATURE] Embed static assets in Go binary
* Refactor/consolidate code and specify public_html via configuration
* Update docs and config template for assets
* Update AUR package pre-requisites and systemd unit
* Include static assets as Buildkite and GitHub artifacts
* Remove references to PUBLIC_DIR
* Only serve assets via embedded filesystem and remove configuration references
* Update authelia-scripts helper to build the embedded filesystem
* Mock the embedded filesystem for unit tests
Add to gitignore to ensure this isn't overwritten.
* Move go:generate to satisfy linter
* [CI] Introduce linting for branch commits with reviewdog
This utilises the GitHub checks API and could be a potential candidate instead of in-line PR reviews.
* [CI] Change reporter to `github-check`
* [CI] Adjust linting in-line PR commentary to execute with linting step
This will ensure that notes pertaining to a version in the BREAKING.md will be published in each of the respective github releases.
All information from:
'## Breaking in $TAG' until the next '## Breaking in $TAG' is included.
* [Buildkite] Optimise pipeline for tagged deployments
Ensure Unit and Integration testing is bypassed for tagged builds.
* Apply suggestions from code review
Co-Authored-By: Clément Michaud <clement.michaud34@gmail.com>
Prior to this change all PR's which are merged into master would result in another run of the Unit and Integration testing.
This is not necessary because all steps have to pass for a PR to be accepted in to master, this will save significant time for deployments to master and reduce overall load to the Buildkite workers.
This change will continue to perform unit and integration testing, however, disables deployment steps in association with dependabot PRs.
Deployment comments on the PR with autheliabot are also disabled.
* [Buildkite] Utilise annotations for artifact and doc bypass notifications
* [Buildkite] Add context to annotations
* [Buildkite] Adjust docs annotation to display for PRs
* [Buildkite] Enable automatic retries for failed github artifact step
This is to handle failures which may occur when attempting to upload assets, per: https://buildkite.com/authelia/authelia/builds/465#537f931f-efc3-4f7b-9527-c927c1425a52.
* [Buildkite] Ensure GitHub artifact step is reported as a failure
When the initial command fails and we remove the release, we need to ensure that the exit status is reported as non-zero to trigger the automatic retry.
* [Buildkite] Fix changelog output for github releases
Fetch is required to grab the latest tag, this will ensure the correct data is generated
* [Buildkite] Only clean tags on pushes to master
Also ensure that master tag is not removed on github API failures.
* [Buildkite] Fix tag publishing for releases
* [Buildkite] Minor tweaks to github changelog output
* Update README.md
Provide badges and references to the AUR for Arch Linux Authelia packages.
Closes#571#572.
* Add systemd unit file
Include the unit in future release artifacts.
* Remove CHANGELOG.md
As of future releases Changelog details will dynamically be generated.
* Update README.md
Add badge for authelia-git package.
* Update Changelog to only publish explicit Docker tag
Do not include Major and Minor versions, as these will change over time.
* Optimise deploy artifacts step
authelia-scripts is not required to publish GitHub artifacts as we utilise [Hub](https://hub.github.com/), this should save ~10 seconds in this step.
* Specify release number in pipeline
* Change buildkite and github published artifacts back to gzip
* Update README.md
* Build docker image upfront in CI and use it in integration tests.
Previously, the development workflow was broken because the container
generated from Dockerfile.CI was used in dev environments but the binary
was not pre-built as it is on buildkite. I propose to just remove that
image and use the "to be published" image instead in integration tests.
This will have several advantages:
- Fix the dev workflow.
- Remove CI arch from authelia-scripts build command
- Optimize CI time in buildkite since we'll cache a way small artifact
- We don't build authelia more than once for earch arch.
* Fix suites and only build ARM images on master or tagged commits
* Optimise pipeline dependencies and Kubernetes suite to utilise cache
* Run unit tests and docker image build in parallel.
* Fix suite trying to write on read only fs.
Co-authored-by: Amir Zarrinkafsh <nightah@me.com>
* Remove Travis and promote Buildkite
* Add Docker Size badge to README.md
* Call MicroBadger webhook to update metadata for shields
Add updateMicroBadger function and refactor publishDockerReadme to be called explicitly instead of on every deployManifest call.
