nixpkgs-upkeep icon indicating copy to clipboard operation
nixpkgs-upkeep copied to clipboard

test packages on the staging, staging-next branches as well as master

Open samuela opened this issue 3 years ago • 3 comments

It's often the case that large, sweeping changes are made on staging/staging-next that break builds. This is problematic due to the massive number of commits between successful and broken versions, making bisecting very annoying. It would be nice to run all of the canary builds on all three branches: master, staging, staging-next.

samuela avatar Apr 18 '22 18:04 samuela

You don't need to bisect builds. Most if not all of the time it is more time effective to take a look at the error and figure out whats wrong from there.

Also building staging all the time is a bad idea because you are going to compile a lot of stdenvs and compilers.

SuperSandro2000 avatar Apr 22 '22 00:04 SuperSandro2000

You don't need to bisect builds. Most if not all of the time it is more time effective to take a look at the error and figure out whats wrong from there.

I've found bisecting to be useful in a number of scenarios. If nothing else, it allows me to go to the author of the breakage with 100% certainty that it was their change that broke the build.

Also building staging all the time is a bad idea because you are going to compile a lot of stdenvs and compilers.

Agreed, but how else do you propose I address the issues raised in this post?

samuela avatar Apr 22 '22 02:04 samuela

Agreed, but how else do you propose I address the issues raised in this post?

I would suggest to build python-updates and staging-next when the PR is older than a day or two to make sure you are not compiling the world which can take 12 hours.

it allows me to go to the author of the breakage with 100% certainty that it was their change that broke the build.

Well, yes, that true. Maybe I fiddled to much with python packages that I gave up on this.

SuperSandro2000 avatar Apr 22 '22 09:04 SuperSandro2000