-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disable Zincati and pinger on non-release builds of production streams #212
Comments
Here's another approach which doesn't require a hidden API with the pipeline and keeps it all localized in the manifest instead: diff --git a/fedora-coreos-base.yaml b/fedora-coreos-base.yaml
index b96e34b..8905d74 100644
--- a/fedora-coreos-base.yaml
+++ b/fedora-coreos-base.yaml
@@ -22,8 +22,9 @@ initramfs-args:
machineid-compat: false
releasever: "30"
-automatic-version-prefix: "30"
-mutate-os-release: "30"
+automatic-version-prefix: "${releasever}.<date:%Y%m%d>.dev"
+mutate-os-release: "${releasever}"
+
# Be minimal
recommends: false
@@ -122,6 +123,13 @@ postprocess:
set -xeuo pipefail
rm -rf /etc/systemd/system/*
systemctl preset-all
+ - |
+ #!/usr/bin/env bash
+ set -euo pipefail
+ source /etc/os-release
+ if [[ $OSTREE_VERSION = *.dev* ]]; then
+ echo "Disabling pinger and Zincati"
+ fi
packages:
# Security ➡️
(This relies on The rationale for this being that we know that for release builds we'll override the OSTree version in the pipeline, so we can have the default versioning scheme hardcoded in the config include a dev marker. That way the default |
@jlebon: By prod mode, is this a mode in the pipeline where a production image is produced from e.g. the I was at first thinking we could just use the stream-specific Having |
Can we use the term "release build" to avoid overloading the term "prod"? @rfairley The thinking is that all branches will have Zincati and pinger disabled by default, and that will be overridden by the pipeline for official release builds, and can be overridden at build time by individual developers. |
Yeah, WFM. We've also been using "official" in https://github.com/coreos/fedora-coreos-pipeline for this. Anyway, updated my comment to make this clearer.
Sorry, the terminology is super confusing here. To restate what @bgilbert said more explicitly, there are two layers here: (1) stream-specific enablement: Zincati and pinger will have drop-ins to explicitly enable it on production streams (i.e. only on |
We want to be able to distinguish between release and non-release builds. To do this, we embed a `.dev` marker in the version string so that the default developer workflow will use this. As mentioned in the previous commit message, this will be overridden for release streams. See coreos/fedora-coreos-tracker#212 for more information about this.
On non-release/local developer builds, we don't want Zincati or pinger to be active by default. Key off of the OSTree version and add a config dropin to do this. See discussions about this in: coreos/fedora-coreos-tracker#212
We want to be able to distinguish between release and non-release builds. To do this, we embed a `.dev` marker in the version string so that the default developer workflow will use this. As mentioned in the previous commit message, this will be overridden for release streams. See coreos/fedora-coreos-tracker#212 for more information about this.
On non-release/local developer builds, we don't want Zincati or pinger to be active by default. Key off of the OSTree version and add a config dropin to do this. See discussions about this in: coreos/fedora-coreos-tracker#212
@jlebon I think this is all covered and can be closed now, right? |
Yes, agreed! |
#163 (comment) contemplates stream-specific enablement for Zincati and the pinger. However, developers will sometimes perform test builds of production streams, e.g. in order to test backports. It's not awful if those builds try to ping or update themselves, but it's aso not helpful and adds reporting noise.
Enable Zincati and the pinger only in release builds of production streams. The code to do that should primarily live in fedora-coreos-config, since cosa shouldn't need to understand that special case in detail, and the pipeline shouldn't be mangling images behind cosa's back. @jlebon and I discussed having a manifest postprocess script look for a magic environment variable, e.g.
FCOS_RELEASE_BUILD
, and condition its behavior accordingly. However, rpm-ostree runs scripts in a bwrap container which doesn't pass through env vars from the cosa invocation.The text was updated successfully, but these errors were encountered: