-
-
Notifications
You must be signed in to change notification settings - Fork 309
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
Make jobs unique #60
Comments
Some stats on the non-uniqueness of (job, system): there are only 431 jobset evaluations (out of 261549) that contain multiple builds with the same (job, system). Mostly gnu:libidn-master, ltsmin:ltsmin-trunk and strategoxt:stratego-libraries-trunk. Generated using:
|
Maybe you explained this already, but how will |
Having different builds within a job is obsolete (issue #60), one should have different job per platform (e.g. build.x86_64-linux).
The per-system presentation doesn't make much sense any more given issue #60. It should be replaced by (say) a grid showing each job per evaluation.
That is, there are now distinct jobs like ‘coreutils.x86_64-linux’ and ‘coreutils.x86_64-darwin’, rather than a single job ‘coreutils’ with multiple builds. This means that testing a job is simpler: $ nix-build pkgs/top-level/release.nix -A coreutils.x86_64-linux See NixOS/hydra#60 for the motivation.
E.g. "build.x86_64-linux" instead of "build". Also, by not using a Hydra input "system" anymore, the set of platforms to build on becomes declarative. See NixOS/hydra#60
@edolstra is this still relevant? You made various changes that contribute to this. Maybe you want to update the description with a list of items that would still have to be done to get this closed. |
Yes, it's still relevant. |
Currently a jobset evaluation can produce multiple builds with the same job name. This is bad because it means jobs don't really have a distinct identity.
This means many job-based comparisons in Hydra are very fuzzy: for instance, finding the last job status change is not well defined if there are multiple jobs with the same name. (E.g. in the previous eval, one "foo" build could have failed while the other succeeded. Then if in the current eval one fails and the other succeeds, we cannot really say if their status changed: they may have both flipped, or both stayed the same. We do use the system type to distinguish between builds, but that's very ad hoc.)
So we should make jobs unique in a jobset eval, i.e., within an eval there should be at most one build with a given job name.
Implementation / consequences:
The text was updated successfully, but these errors were encountered: