| 20 Jun 2024 |
 hexa | * as an example\ | 12:00:59 |
| hexa | * as an example | 12:01:01 |
| hexa | * I can push changes to the tracked branch and evaluate them, which results in the changed jobs being built, but these 93 jobs simply won't | 12:01:33 |
| hexa | hm, these are all fods which have broken urls | 12:04:24 |
 vcunat | FODs are hard. Normally hydra won't rebuild them unless the output hash changes. | 12:18:00 |
| vcunat | But just changing URL won't change that. | 12:18:12 |
| vcunat | * FODs are hard. Normally hydra won't create a new job unless the output hash changes. | 12:18:49 |
| vcunat | So you're stuck with the old job tied to the incorrect .drv | 12:19:03 |
| vcunat | As an ugly workaround, you could evaluate in a _different) jobset, for example. That will get a new .drv (if you evaluate such commits right away), getting you eventually binaries and then you can just restart these failed jobs to get the cached results and you'll get green. | 12:20:27 |
| vcunat | (I know this because sometimes we run into this on hydra.nixos.org) | 12:21:09 |
| vcunat | I'm not sure if there's a good solution. Maybe for FODs the equivalence on job creation should be on .drv hash and not output hash. (But we probably want to keep the old behavior for non-FODs.) | 12:23:03 |
| vcunat | However, I don't know the codebase at all and I can't perl. | 12:24:40 |
| vcunat | Job creation might not suffice, now that I think of it. There's also a mechanism for caching failure from another job, so same there. | 12:30:12 |
| vcunat | * Job creation might not suffice, now that I think of it. There's also a mechanism for failure cached from another job, so same there. | 12:30:26 |
| hexa | the old ones cleared up now | 13:02:58 |
| hexa | I'm not sure if fixing the fods in new evals die that, but that would be surprising to me | 13:03:17 |
| 21 Jun 2024 |
|  @linus:schreibt.jetzt left the room. | 14:05:46 |
