Meeting Notes

building a cache on Gitlab isn't the problem but rather how to harvest and publish the cache
Windows cache is signed, so we are also stuck on the signing problem here
- this isn't a security issue but a performance optimization for signing the final installers
- we could skip this for now
where should the cache builds live? sysadmin/ci-management
- somewhat similar to the seed job, similar regarding access rights, so let's use that
does this need extended build times?
- average Android cache build job runtime is <= 20min, but those are incremental
- even timeout is not blocking, we just run the job incrementally
- by using sysadmin/ci-management we already get extended job runtimes (up to 6h)
Ben to set up an ssh key for craft cache updates
- done, $CRAFT_UPLOAD_KEY env var contains the key for uploading, account is locked to sftp upload
Hannah to set up a craft cache job there for testing, starting with Android Qt6 as that wont break anything

Gitlab 500kB log limit is hard to change
Craft should put extended logs into Gitlab artifact
- Option 1: tee the output into a file, let's you see the full output below 500kB right away, but nothing beyond that until the build is done
- Option 2: kdesrc-build like behavior: let's you see the progress, will require downloading the log to see any error

Linux WebEngine build kills other VMs
what's the maximum memory use for the WebEngine build?
special handling for WebEngine would needs awkward splits of the cache build jobs due to this being in the middle of the dependency chain
would extra hardware solve this? we can upgrade the worker to 128GB RAM for limited amount of money

Ingo working on our own solution as the existing solutions didn't work for us
using a job queue on the signer that the Gitlab workers upload to
results are uploaded to another queue that the workers then poll
currently in Ingo's Invent namespace, needs to move to the main repos
also going to be used for uploads and website publishing, which have similar security requirements
implements APK and APPX signing
remaining issue is how to limit who can feed things into this
Gitlab protected variables would solve this: those are set on repos/groups and only on protected branches (master, stable release branches),
- they would contain the credentials for uploading to the signing service
- this is already in use for CI artifact uploads
appimage signing currently done but yet to be implemented in the new system

this is also (implicitly) provided by Jenkins
we link to random artifact for downloads on Jenkins, going to be less obvious with Gitlab artifacts
- sometimes due to lacking proper releases
Jenkins also gives us a full overview status page
we also need proper solutions for all that, but that's a separate discussion