Re: Parallel guix builds can trample?

[Philip Beadling]

Thanks for reply Ricardo. 

The source in each one will be slightly different and although I only specify commit id in the package, each package commit id will reference a different branch.

To give some context, each commit id relates to a different Pull Request branch. After my integration source branch is updated - the system then rebuilds any open PRs with the new integration update merged on top.  This checks that the PRs remain mergable against the heat of integration. 

Because some PRs sit in a known broken state, it was possible to detect the problem.

I've seen the issue very sporadically for a few months, but at the moment a large number of open and broken PRs have revealed the problem to be more frequent.

Is there a way to output source hash in the log, to be sure of this? 

One idea I had today is to try to reproduce the problem outside of my CI system, just by manually recreating 12 local channels, one with a known commit reference to a break in it, and have a shell script loop over, building each in the background, then waiting for all builds to terminate, and looking at their return codes.  If they all pass apart from the known broken clone, then repeat.  It won't solve the problem but will remove any other source of the problem, and can be left running in fast succession. 

---

From: Ricardo Wurmus <rekado@elephly.net>
Sent: Tuesday, 11 January 2022, 23:17
To: Phil
Cc: guix-devel@gnu.org
Subject: Re: Parallel guix builds can trample?

Phil <phil@beadling.co.uk> writes:

> I update the same single package on each channel locally with a
> different git commit id and package version.  So 12 variations of the
> same package, accessing different commit ids, in the same package's
> source repo, and having different package versions in Guix.

Do they have different source hashes too?  The hash is what uniquely
identifies the source, not the version or commit.

--
Ricardo