| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
Now CI builds triggered from tagged releases will always have the correct version. No need for manually updating a separate file.
Compare to the remote GH release tag published, rather than contents of a `VERSION` file. `VERSION` file remains in source for now as prior releases still rely on it for an update notification.
- Can more easily express a string subslice. - Lighter weight: 9.3M vs 1.7M. - Drawback, no YAML input/output support. If `yq` is preferred, the `v` prefix could be removed via BASH easily enough.
There was a problem hiding this comment.
LGTM 👍🏼
One tiny nitpick (style) 🚀
Sorry, something went wrong.
There was a problem hiding this comment.
Some review comments for context to the latest changes.
Sorry, something went wrong.
| #### Version | ||
| #### Minimum supported version | ||
|
|
||
| We make use of build-features that require a recent version of Docker. Depending on your distribution, please have a look at [the official installation documentation for Docker](https://docs.docker.com/engine/install/) to get the latest version. Otherwise, you may encounter issues, for example with the `--link` flag for a [`#!dockerfile COPY`](https://docs.docker.com/engine/reference/builder/#copy) command. |
There was a problem hiding this comment.
I removed the --link example as I think that has a fallback behaviour for compatibility and the information here with link doesn't provide that context.
Docker v23 was released Feb 2023. It enables BuildKit by default. It makes for a good baseline (for building the image), instead of just "recent version", while being a little vague on earlier version support for brevity.
Sorry, something went wrong.
| - To get the latest version for your distribution, please have a look at [the official installation documentation for Docker](https://docs.docker.com/engine/install/). | ||
| - If you are using a version of Docker prior to v23.0, you will need to enable BuildKit via the ENV [`DOCKER_BUILDKIT=1`](https://docs.docker.com/build/buildkit/#getting-started). | ||
|
|
||
| If you are not using `make` to build the image, note that you will need to provide `DOCKER_BUILDKIT=1` to the `docker build` command for the build to succeed. |
There was a problem hiding this comment.
This page no longer makes mention of the make build command, it doesn't add much value to the reader so seemed like noise?
Sorry, something went wrong.
| The `Dockerfile` includes several build [`ARG`][docker-docs::builder-arg] instructions that can be configured: | ||
|
|
||
| The `Dockerfile` takes additional, so-called build arguments. These are | ||
| - `DOVECOT_COMMUNITY_REPO`: Install Dovecot from the community repo instead of from Debian (default = 1) | ||
| - `DMS_RELEASE`: The image version (default = edge) | ||
| - `VCS_REVISION`: The git commit hash used for the build (default = unknown) | ||
|
|
||
| 1. `VCS_VERSION`: the image version (default = edge) | ||
| 2. `VCS_REVISION`: the image revision (default = unknown) | ||
| !!! note | ||
|
|
||
| When using `make` to build the image, these are filled with proper values. You can build the image without supplying these arguments just fine though. | ||
| - `DMS_RELEASE` (_when not `edge`_) will be used to check for updates from our GH releases page at runtime due to the default feature [`ENABLE_UPDATE_CHECK=1`][docs::env-update-check]. | ||
| - Both `DMS_RELEASE` and `VCS_REVISION` are also used with `opencontainers` metadata [`LABEL`][docker-docs::builder-label] instructions. | ||
|
|
||
| [docs::env-update-check]: https://docker-mailserver.github.io/docker-mailserver/latest/config/environment/#enable_update_check | ||
| [docker-docs::builder-arg]: https://docs.docker.com/engine/reference/builder/#using-arg-variables | ||
| [docker-docs::builder-label]: https://docs.docker.com/engine/reference/builder/#label |
There was a problem hiding this comment.
Revised this section, there is technically another ARG for log output but I've omitted that. The Dovecot one seemed relevant to the reader.
I've clarified the revision context, and to an extent DMS_RELEASE, with some insights that might be relevant to the reader for custom images.
Sorry, something went wrong.
| @ DOCKER_BUILDKIT=1 docker build \ | ||
| --tag $(IMAGE_NAME) \ | ||
| --build-arg VCS_VERSION=$(shell git rev-parse --short HEAD) \ | ||
| --build-arg VCS_REVISION=$(shell cat VERSION) \ | ||
| . |
There was a problem hiding this comment.
Since v23 is now the min version advised for building and the related docs make note of DOCKER_BUILDKIT=1, the ENV is removed from here.
The build args have also been dropped. The inputs were around the wrong way, and generally for building an image that isn't a release these inputs aren't useful. If users need them they should prefer a more explicit command like we do with CI.
Not part of the image releases, so I don't see this as a breaking change.
Sorry, something went wrong.
|
Documentation preview for this PR is ready! 🎉 Built with commit: 98a2283 |
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM 👍🏼
I will wait for @casperklein before merging - please be advised that this is a high-priority PR - I'd like to publish v13.0.1 by the end of the day :)
Sorry, something went wrong.
Is it possible to release this DKIM hotfix without this merge? |
Sorry, something went wrong.
|
Issue is fixed currently with :edge version |
Sorry, something went wrong.
It doesn't feel okay to run edge on a stable environment. |
Sorry, something went wrong.
|
One regression I noticed: [[ ${ENABLE_UPDATE_CHECK} -eq 1 ]] && [[ ${DMS_RELEASE} != 'edge' ]] Previously, when you are on a tagged release that contained a bug of some kind and got advised by us to switch to edge, because it was fixed there already, you would still be notified via update-check, when a new tagged release is available, so you could switch back.
No real issues if you ask me. In #3659 the root cause for the mail flood wasn't identified. But not related to the update-check IMO. #3662 is already fixed. The initial question was, if we want to check against the latest release or the VERSION file in the master branch. Checking the release is the way to go. Otherwise the PR looks good 👍 |
Sorry, something went wrong.
I don't consider that desirable as a default. If a user is switching to :edge temporarily and would like this kind of notification they can now set the DMS_RELEASE ENV with the release tag they want to monitor for newer updates since with (eg: `DMS_RELEASE='v12.1.0'), and they will get that functionality. We've already had reports of the prior behaviour not being desired on :edge (granted they could opt out via UPDATE_CHECK=0). If you'd prefer to source the version tag from a git command to find the latest tag, that could be done instead, likewise UPDATE_CHECK could then be given a build arg to default it to disabled on :edge. Alternatively, if you'd like the DMS_RELEASE ENV to be documented for :edge users, I can add that.
There wasn't anything in #3659 to say they expected a notification on :edge, and I can't say that I'd want that behaviour on other software I'd run on a nightly/beta/edge like release channel. Update notifications on :edge should be opt-in. #3662 shouldn't have been raised in the first place as :edge shouldn't need to care about stable releases. Regardless, with this PR it's resolved with an alternative approach.
If you can refer to other software that notifies users of stable updates on an :edge equivalent release channel, I'd be more supportive of that. Otherwise I'd rather our users express actual demand for the functionality and I'll implement/document it. |
Sorry, something went wrong.
|
I'll publish v13.0.1 shortly 🚀 (EDIT: Done!) |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Description
We have had 3 concerns encountered related to this feature in the past.
Resolved by:
Past concerns addressed:
Additional context
Applies changes were originally proposed here:
ℹ️ Note:
⚠️ Caution:
yq vs jaq
I have expressed interest in yq previously for managing DKIM / rspamd config (and processing JSON output from step CLI for TLS cert tools):
However it weighs 9.3MB vs an alternative jaq at 1.7MB, which in this case was simpler to query the JSON field for the tag and strip the v prefix character.
See the jaq link for preference of it over jq. Docs wise, if using jaq elsewhere in DMS scripts you can follow the jq docs, or see the jaq README for some additional features/capabilities.
Type of change
Checklist: