Due to the unpredictability of changes that Renovate can submit this PR will allow us to control the number of jobs that will run simultaneously per step.
Instead of generating our changelog based on crude modifications utilising git log we now utilise conventional-changelog.
conventional-changelog utilises the angular commit structure to categorise and display the changelog for 3 types (fix,feat,perf) and each of the change scopes are identified in the changelog too.
An example of the output for v4.26.0 can be found below:
# [4.26.0](https://github.com/authelia/authelia/compare/v4.25.2...v4.26.0) (2021-02-02)
### Bug Fixes
* **handlers:** refresh user details on all domains ([#1642](https://github.com/authelia/authelia/issues/1642)) ([60ff16b](60ff16b518))
### Docker Container
* `docker pull authelia/authelia:4.26.0`
* ci: consider .all-contributorsrc a docs file for the pipeline
This change prevents the unit/integration testing and image deployment similar to other docs only changes.
This PR modifies the Buildkite CI pipeline with the following changes:
* Add `SECURITY.md` to CI_BYPASS
* Skip Docker {amd64,arm32v7,arm64v8} builds for renovate PRs
* Ensure Deploy Manifest step only is assigned to deployment nodes
This change adds a new integration testing suite "CLI".
The intent of this suite is to test, validate and capture coverage for Authelia's commands via the CLI.
* [FEATURE] Add API docs and swagger-ui
This change will serve out swagger-ui at the `/api/` root path.
* Update descriptions and summaries in API spec
* Utilise frontend assets from unit testing for Docker build steps
* Fix tag for /api/user/* endpoints
* Fix response schema for /api/user/info/2fa_method
* Template and inject the session name during runtime into swagger-ui
This change also factorises and renames index.go into template.go, this can now be generically utilised to template any file.
* Fix integration tests
* Add U2F endpoints
* Change swagger directory to api
This change is to more closely conform to the golang-standards project layout.
* Add authentication for u2f endpoints
* Modify u2f endpoint descriptions
* Rename and fix u2f 2fa sign endpoints
* Fix request body for /api/secondfactor/u2f/sign endpoint
Co-authored-by: James Elliott <james-d-elliott@users.noreply.github.com>
* [CI] Exclude non-coverage files from codecov upload
* Ignore React serviceWorker.ts for coverage
As we do not utilise service workers in React gives more accurate coverage percentages when ignored.
* Added `ActiveDirectory` suite for integration tests with Samba AD
* Updated documentation
* Minor styling refactor to suites
* Clean up LDAP user provisioning
* Fix Authelia home splash to reference correct link for webmail
* Add notification message for password complexity errors
* Add password complexity integration test
* Rename implementation default from rfc to custom
* add specific defaults for LDAP (activedirectory implementation)
* add docs to show the new defaults
* add docs explaining the importance of users filter
* add tests
* update instances of LDAP implementation names to use the new consts where applicable
* made the 'custom' case in the UpdatePassword method for the implementation switch the default case instead
* update config examples due to the new defaults
* apply changes from code review
* replace schema default name from MSAD to ActiveDirectory for consistency
* fix missing default for username_attribute
* replace test raising on empty username attribute with not raising on empty
Co-authored-by: James Elliott <james-d-elliott@users.noreply.github.com>
This change will allow us to collect frontend code coverage from our Selenium based integration tests.
Given that the frontend is embedded into the Go binary and the integration tests run with a compiled binary in Docker this poses some issues with the instrumented code and the ability for it to run in this manner. To fix this we need to relax Authelia's CSP for the integration tests. This is achieved by setting the env variable `ENVIRONMENT` to `dev`.
* [FEATURE] Docker simplification and configuration generation
The Authelia binary now will attempt to generate configuration based on the latest template assuming that the config location specified on startup does not exist. If a file based backend is selected and the backend cannot be found similarly it will generate a `user_database.yml` based a template.
This will allow more seamless bootstrapping of an environment no matter the deployment method.
We have also squashed the Docker volume requirement down to just `/config` thus removing the requirement for `/var/lib/authelia` this is primarily in attempts to simplify the Docker deployment.
Users with the old volume mappings have two options:
1. Change their mappings to conform to `/config`
2. Change the container entrypoint from `authelia --config /config/configuration.yml` to their old mapping
* Adjust paths relative to `/etc/authelia` and simplify to single volume for compose
* Add generation for file backend based user database
* Refactor Docker volumes and paths to /config
* Refactor Docker WORKDIR to /app
* Fix integration tests
* Update BREAKING.md for v4.20.0
* Run go mod tidy
* Fix log_file_path in miscellaneous.md docs
* Generate config and userdb with 0600 permissions
* Fix log_file_path in config.template.yml
* [CI] Add Codecov support
* [CI] Capture backend coverage from integration tests
* [CI] Remove unnecessary artifacts for coverage build
* [CI] Only run coverage elements where necessary
* [CI] Simplify post-command hook
* Fix yarn dependencies and collect coverage
* [CI] Include cmd/authelia/ path in coverage
* [CI] Exclude internal/suites/ in coverage
Closes#1061.
Prior to this change if there was a branch/PR build which had not yet published manifests and a master build running simultaneously, assuming the master build finished publishing manifests before former it would clean up the architecture tagged containers (-{amd64,arm32v7,arm64v8}) which would result in the manifest step failing for the branch or PR build.
These should not be considered in either of the clean up steps because they're removed as part of a successful manifest being published.
Pushes to master and tagged releases will have now have explicit dependencies for steps. This is specifically to prevent darwin based builds holding up execution of other steps which should not have a dependence.
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.
James Elliott
Amir Zarrinkafsh
renovate[bot]
vdot0x23
Clément Michaud