You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Capturing some discussions with @dustymabe. Currently, the build and build-arch jobs are very similar. Where they differ is that the build job has extra logic for handling OSTree archiving, build-arch job and release job triggering (and rerun logic), and the build-arch job has the remote session stuff.
For a while, we've discussed building x86_64 using the same code as the other arches. We could do this by teaching the build-arch job to build for x86_64 (this doesn't necessarily imply using a remote builder, but it'd be simpler if it were). Then, all the business logic around e.g. early multi-arch forking, reruns, the release job, etc... would be captured in the build job, which is now more of a controller job that spawns the other jobs and monitors them. The outside interface for the build job would probably not change much.
This ideally would allow us to reduce complexity around locks and races and make unified reporting easier.
The text was updated successfully, but these errors were encountered:
Another good argument for this is that whenever we're waiting for the multi-arch or release jobs to complete (4c02574), we're hogging lots of resource quota for nothing, possibly preventing other jobs for other streams from starting.
Capturing some discussions with @dustymabe. Currently, the
build
andbuild-arch
jobs are very similar. Where they differ is that thebuild
job has extra logic for handling OSTree archiving,build-arch
job andrelease
job triggering (and rerun logic), and thebuild-arch
job has the remote session stuff.For a while, we've discussed building x86_64 using the same code as the other arches. We could do this by teaching the
build-arch
job to build for x86_64 (this doesn't necessarily imply using a remote builder, but it'd be simpler if it were). Then, all the business logic around e.g. early multi-arch forking, reruns, the release job, etc... would be captured in thebuild
job, which is now more of a controller job that spawns the other jobs and monitors them. The outside interface for thebuild
job would probably not change much.This ideally would allow us to reduce complexity around locks and races and make unified reporting easier.
The text was updated successfully, but these errors were encountered: