lix-project/buildbot-nix
15
0
Fork 0
Code Issues 13 Pull requests 7 Packages Projects Releases Wiki Activity

Don't rebuild Verified:+1 NO_CODE_CHANGE CL amendments #15

New issue
Open
opened 2024-05-31 20:34:03 +00:00 by jade · 4 comments
jade commented 2024-05-31 20:34:03 +00:00
Owner
Copy link

Stuff like: https://gerrit.lix.systems/c/lix/+/1157 can get stamped as Verified:-1 falsely due to a cancellation even though it should not be CI'd in the first place.

I think the conditions for CI'ing a CL update should be that: (it's not Verified:+1) OR (amendment is not NO_CODE_CHANGE); that is, you should be able to force a re-CI of a broken CL, but changing commit messages or no-code-change rebases will not trigger re-CI otherwise.

Stuff like: https://gerrit.lix.systems/c/lix/+/1157 can get stamped as Verified:-1 falsely due to a cancellation even though it should not be CI'd in the first place. I think the conditions for CI'ing a CL update should be that: `(it's not Verified:+1) OR (amendment is not NO_CODE_CHANGE)`; that is, you should be able to force a re-CI of a broken CL, but changing commit messages or no-code-change rebases will not trigger re-CI otherwise.
jade commented 2024-05-31 20:42:24 +00:00
Author
Owner
Copy link

Oh NO, I just had a realization: these builds aren't identical since we put the git revision into the binary. I would really like to put the specialization to the specific git revision into a separate derivation given that information. Unsure the exact way to do it, objcopy would be trivial though.

Oh NO, I just had a realization: these builds aren't identical since we put the git revision into the binary. I would *really* like to put the specialization to the specific git revision into a separate derivation given that information. Unsure the exact way to do it, objcopy would be trivial though.
pennae commented 2024-06-01 08:37:41 +00:00
Owner
Copy link

doesn't NO_CODE_CHANGE also happen for rebases? we absolutely want to re-CI those. not sure how hard it would be to detect that the base commit is still the same to make that possible

doesn't `NO_CODE_CHANGE` also happen for rebases? we *absolutely* want to re-CI those. not sure how hard it would be to detect that the base commit is still the same to make that possible
jade commented 2024-06-01 16:29:10 +00:00
Author
Owner
Copy link

Don't think so, I think those are TRIVIAL_REBASE or something.

Don't think so, I think those are TRIVIAL_REBASE or something.
pennae commented 2024-06-01 17:47:19 +00:00
Owner
Copy link

ok yeah, seems we got those mixed together somehow. sounds good then. perhaps the best way to do this would be to have buildbot poll the verified state on each cl before attempting?

ok yeah, seems we got those mixed together somehow. sounds good then. perhaps the best way to do this would be to have buildbot poll the verified state on each cl before attempting?
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
forkos
faster-depinfo
profiler
jade/report-eval-errors
bring-back-old-gerrit-reporting
fix-reporting
incoming-ref-for-non-flakes
local-stores
non-flakes-rerun
prepare-for-non-flakes
non-flakes
jade/deny-flake-config
fallable-binary-cache
gerrit
better-gerrit
puck/gerrit-changes
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: lix-project/buildbot-nix#15
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?