-
-
Notifications
You must be signed in to change notification settings - Fork 48
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
Mechanism for triggering template build #3935
Comments
This would probably be a good idea. |
Preparation for auto-build-template script, avoid code duplication. QubesOS/qubes-issues#3935
This require little changes to update-repo: - not stripping dist flavors for linux-template-builder component - handling simplified repository layout (no dom0/fc25 subdir) - setting TEMPLATE_NAME variable - calculating it is done in various makefiles and need to be done before parsing templates.spec; unfortunately variables set in makefile aren't available to $(shell ...) in the very same makefile, so this needs to be set earlier QubesOS/qubes-issues#3935
Allow easily get calculated template name. While the command looks simple, it needs to be called with right environment variables (especially - with settings in builder.conf). QubesOS/qubes-issues#3935
If builder.conf is generated by setup script, it is set, but otherwise it isn't. And because of this, various scripts guess release version based on repository dir name. Lets have it in one place. QubesOS/qubes-issues#3935
Yet another place where template flavors needs not to be stripped when handling template. QubesOS/qubes-issues#3935
Since templates can be now handled as other rpm packages, there is no need for separate section. QubesOS/qubes-issues#3935
This require little changes to update-repo: - not stripping dist flavors for linux-template-builder component - handling simplified repository layout (no dom0/fc25 subdir) - setting TEMPLATE_NAME variable - calculating it is done in various makefiles and need to be done before parsing templates.spec; unfortunately variables set in makefile aren't available to $(shell ...) in the very same makefile, so this needs to be set earlier. See https://savannah.gnu.org/bugs/?10593 QubesOS/qubes-issues#3935
Allow easily get calculated template name. While the command looks simple, it needs to be called with right environment variables (especially - with settings in builder.conf). QubesOS/qubes-issues#3935
If builder.conf is generated by setup script, it is set, but otherwise it isn't. And because of this, various scripts guess release version based on repository dir name. Lets have it in one place. QubesOS/qubes-issues#3935
Yet another place where template flavors needs not to be stripped when handling template. QubesOS/qubes-issues#3935
Since templates can be now handled as other rpm packages, there is no need for separate section. QubesOS/qubes-issues#3935
This allows to reuse standard update-repo-* and sign-* make targets. QubesOS/qubes-issues#3935
Don't assume UPDATE_REPO contains trailing slash, there may be no more subdirectories (templates-* repos). QubesOS/qubes-issues#3935
This require little changes to update-repo: - not stripping dist flavors for linux-template-builder component - handling simplified repository layout (no dom0/fc25 subdir) - setting TEMPLATE_NAME variable - calculating it is done in various makefiles and need to be done before parsing templates.spec; unfortunately variables set in makefile aren't available to $(shell ...) in the very same makefile, so this needs to be set earlier. See https://savannah.gnu.org/bugs/?10593 QubesOS/qubes-issues#3935
Allow easily get calculated template name. While the command looks simple, it needs to be called with right environment variables (especially - with settings in builder.conf). QubesOS/qubes-issues#3935
If builder.conf is generated by setup script, it is set, but otherwise it isn't. And because of this, various scripts guess release version based on repository dir name. Lets have it in one place. QubesOS/qubes-issues#3935
Yet another place where template flavors needs not to be stripped when handling template. QubesOS/qubes-issues#3935
Since templates can be now handled as other rpm packages, there is no need for separate section. QubesOS/qubes-issues#3935
It already had custom recipe, but since now it got Makefile.builder file, really bypass the default one. QubesOS/qubes-issues#3935
qubes-template-whonix-gw-14 qubes-template-whonix-gw-14 Upload failure not detected? Out of disk space? https://yum.qubes-os.org/r4.0/templates-community-testing/rpm/ has:
By the way, all older templates can all be purged to save disk space. |
It is, for 3.2 (not 4.0), here: https://yum.qubes-os.org/r3.2/templates-community-testing/rpm/ |
QubesOS/updates-status#572 (comment)
There's was no notification I guess such a notification if upload actually happened could save a some time in future in case it fails for some reason. |
Sort of. This is because it wasn't uploaded. Because there was already newer package: QubesOS/updates-status#593 |
Hello, Sorry, I did not tested yet but the key D85EE12F967851CCF433515A2043E7ACC1833B9C is good for me for building templates. |
Hello, I'm only starting to test this. I'm not sure where I should create specific archlinux configuration. Should I put it there: |
The latter. |
This enables use of different mirrors. Specifify fastestmirror=1 explicitly for templates repository, as it has the biggest impact there. QubesOS/qubes-issues#3935 (cherry picked from commit 217d223)
@unman what key do you want to use for signing build requests? I have two of them:
You tried the second one already, but I want explicit confirmation. |
Ok, I read this as "use 4B1F400DF25651B53C4141B38B3F30F9C8C0C2EF for build commands access list" |
Yes, sorry. You've understood my somewhat gnomic comment aright. |
Done. |
Using...
Builds templates for Qubes R4.0. What's the command for Qubes R4.1? |
Comment out from
|
This is all done for quite some time already. |
Right now template build require direct access to build machine. This is bad for various reasons, including:
We've using a better mechanism for individual packages for some time. It consists of:
This works well for normal packages, lets do something similar for templates.
The problem here is there is no natural place for template version tag - template consists of more than just linux-template-builder - in many cases we need to build new template after just updating individual packages (which doesn't involve any change in linux-template-builder).
I propose using something similar to #2573 for triggering the build too. The work flow would be:
make build-template-in-dispvm
)Open questions:
How build trigger command should look like (what we need there)? My current idea:
For example:
build-template r4.0 fc28+minimal 201805171636
Do we need templates-itl-testing and templates-community-testing repositories and upload templates there first? And the use similar workflow to migrate them later to final repositories?
Replay protection - in the example above I've added TIMESTAMP (which will be used as
%release
part of template version) exactly for this reason. The script would verify if it isn't too far in the past. Any better idea?Template package version is pretty meaningless right now (it's template builder version (but not builder plugin - containing most actual building scripts) + timestamp). Maybe we could use this occasion to change this too? For example specify template version manually too? Or build it based on qubes version (3.2.x for templates for Qubes 3.2 etc)?
This all would for example allow @adrelanos to trigger new Whonix template build or @fepitre for Fedora and CentOS, or @ptitdoc for Archlinux, or @unman for Debian.
cc @andrewdavidwong
The text was updated successfully, but these errors were encountered: