Proof of concept
@MartijnBraam: I thought about working on this in parallel, while I'm doing the pmbootstrap build_order
stuff, there's a lot that can be done in all other parts already. Do you agree with this list and have time fill out the checkboxes?
("bpo" means build.postmarketos.org here)
queue_update job
-
put a "queue_update" manifest either in this repository or pmaports.git -
trigger this job whenever something gets pushed to the pmaports repository (as PoC on all branches, echo "hello world"
would do for starters) -
use fake output for pmbootstrap build_order
for now:
[{"pkgname": "hello-world", "version": "1-r4", "repo": "main"}, {"pkgname": "devicepkg-dev", "version": "0.5-r0", "repo": "main"}]
-
submit that to bpo API (together with the secret API key and branch)
update API call
-
update the build queue (bpo): - for each package in the new queue:
- if the package is in the queue already
- with a different version:
-
if it's running: stop via sr.ht api -
remove from queue -
add the package again with the new version
-
- with the same version:
-
keep the entry
-
- with a different version:
- if the package is not in the queue:
-
add it to the queue
-
- if the package is in the queue already
- for each package in the new queue:
-
add test cases for that logic (to save us from trouble in the future!)
single package build job
-
create an "build" job manifest in the bpo repo ( echo "hello world"
for starters) - extend the update api call: for each arch, when there's no build job running for the given branch:
-
submit a new build job for the first entry in the queue (with that branch + arch as parameters)
-
-
when the build job is through: run bpo api call and report success or failure -
on failure: bpo sets the queue status for that entry to FAILED -
on success: bpo picks the next job (of same branch+arch) in the queue, if there is any -
check that it reports the status nicely in the web UI -
actually build the package in the job pmbootstrap build --force --strict --arch=$arch $pkgname
package uploading
I think we need to store a full copy of the binary packages repository on build.postmarketos.org. Because creating the packages index requires having all packages available. We can sync the mirrors from there.
-
single package job: upload the resulting package to a temporary WIP/ branch/
folder/$arch folder (e.g. WIP/master/main/x86_64/, main is from the aport folder) -
extend "on success" at bpo: when this was the last package in the queue, move the new packages in WIP/$branch/*/$arch
to the binary repository (postmarketos/$branch/*/$arch
) -
bpo: update the package index -
bpo: delete old packages ( pmbootstrap -y zap -m
)
polishing
-
single package build job: before building, ask bpo if the job is still in the queue and abort otherwise -
only run "queue_update" when pushing to a whitelist of branches (right now only containing master
) -
pmos build API: make sure to process only one "queue_update" request at once to avoid race conditions
blocked by missing pmbootstrap code
-
real "pmbootstrap build_orderrepo_missing" (pmbootstrap!1717 (merged)) -
add the WIP repository while building packages and use it (needed to build packages that depend on other new packages, think of a plasma mobile rebuild) (pmbootstrap!1718 (merged))
Edited by Oliver Smith