Skip to content
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

Consider building x86_64 using build-arch and transforming build into a controller job #826

Open
jlebon opened this issue Feb 28, 2023 · 2 comments

Comments

@jlebon
Copy link
Member

jlebon commented Feb 28, 2023

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.

@jlebon
Copy link
Member Author

jlebon commented Feb 28, 2023

The code in coreos/coreos-ci-lib#140 could be useful for the "spawn and monitor" bits.

@jlebon
Copy link
Member Author

jlebon commented Mar 14, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant