1
0
Fork 0
vaultwarden-test/hooks
BlackDex 467ecfdc99
Add support for Quay.io and GHCR.io as registries
- Added support for Quay.io
- Added support for GHCR.io

To enable support for these container image registries the following needs to be added.

As `Actions secrets and variables` - `Secrets`
- `DOCKERHUB_TOKEN` and `DOCKERHUB_USERNAME`
- `QUAY_TOKEN` and `QUAY_USERNAME`

As `Actions secrets and variables` - `Variables` - `Repository Variables`
- `DOCKERHUB_REPO`
- `GHCR_REPO`
- `QUAY_REPO`

The `DOCKERHUB_REPO` currently configured in `Secrets` can be removed if wanted, probably best after this PR has been merged.

If one of the vars/secrets are not configured it will skip that specific registry!
2023-03-23 16:38:27 +01:00
..
arches.sh Add support for Quay.io and GHCR.io as registries 2023-03-23 16:38:27 +01:00
build Add support for Quay.io and GHCR.io as registries 2023-03-23 16:38:27 +01:00
pre_build Add support for Quay.io and GHCR.io as registries 2023-03-23 16:38:27 +01:00
push Add support for Quay.io and GHCR.io as registries 2023-03-23 16:38:27 +01:00
README.md Project renaming 2021-04-27 23:18:32 +02:00

The hooks in this directory are used to create multi-arch images using Docker Hub automated builds.

Docker Hub hooks provide these predefined environment variables:

  • SOURCE_BRANCH: the name of the branch or the tag that is currently being tested.
  • SOURCE_COMMIT: the SHA1 hash of the commit being tested.
  • COMMIT_MSG: the message from the commit being tested and built.
  • DOCKER_REPO: the name of the Docker repository being built.
  • DOCKERFILE_PATH: the dockerfile currently being built.
  • DOCKER_TAG: the Docker repository tag being built.
  • IMAGE_NAME: the name and tag of the Docker repository being built. (This variable is a combination of DOCKER_REPO:DOCKER_TAG.)

The current multi-arch image build relies on the original vaultwarden Dockerfiles, which use cross-compilation for architectures other than amd64, and don't yet support all arch/distro combinations. However, cross-compilation is much faster than QEMU-based builds (e.g., using docker buildx). This situation may need to be revisited at some point.

References