~sircmpwn/sr.ht-discuss

3 3

Do not rebuild same commit?

Details
Message ID
<20200714074407.kigxqnkmzqav74g4@lucy>
DKIM signature
missing
Download raw message
Hi,

I was thinking whether it would be a good idea to introduce a flag for
builds.sr.ht which tells the platform to not rebuild a commit if it was already
successfully build.

Usecase: In the early-development phase of a project, I like to play around with
feature-branches which I change until I like what I have and then fast-forward
master. That means that master gets the commit which was already built and
re-starts a build (see [0] and [1] for example).
I mean, I don't mind that, but I do actually not care about the build at all
because the output is the same anyways.
Maybe that's a case where an optional optimization would be possible.

What do you think?


[0] https://builds.sr.ht/~matthiasbeyer/job/251251
[1] https://builds.sr.ht/~matthiasbeyer/job/254488

-- 
Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer
Details
Message ID
<C46CLCN59JID.3U1X97M91HGMV@homura>
In-Reply-To
<20200714074407.kigxqnkmzqav74g4@lucy> (view parent)
DKIM signature
pass
Download raw message
Not a great idea. It'd be difficult to do - where do we store the list
of built changes? builds.sr.ht isn't responsible for that, so it'd fall
on git.sr.ht, presumably. Does it put them in redis? Does this get
expensive?

Also, after you merge or rebase commits from your feature branch to
master, their hash changes. So now we're deep comparing commits, and we
have to store the full patch somewhere instead of just the sha to know
that we've already built it.
Details
Message ID
<20200714124144.5p3bu2gu5quem6ze@hoshi>
In-Reply-To
<C46CLCN59JID.3U1X97M91HGMV@homura> (view parent)
DKIM signature
missing
Download raw message
On 14-07-2020 08:32:46, Drew DeVault wrote:
> Also, after you merge or rebase commits from your feature branch to
> master, their hash changes. So now we're deep comparing commits, and we
> have to store the full patch somewhere instead of just the sha to know
> that we've already built it.

No, you misunderstood that part. I meant that only the hash is used to check
whether the commit is already built, which would prevent building in
fast-forward-merge cases, but not in other cases.

Same hash: no rebuild.
Other hash (rebase, cherry-pick, whatever): normal build.

Matthias
Details
Message ID
<fdfc7b9d-2e05-4ea7-a6bc-b624eb29b610@www.fastmail.com>
In-Reply-To
<C46CLCN59JID.3U1X97M91HGMV@homura> (view parent)
DKIM signature
fail
Download raw message
DKIM signature: fail
You definitely don't want to prevent a rebuild if the hash has changed
because the underlying source may still be different and the unchanged
patch may react differently with different code in other parts of the
code base causing failures that have now been skipped.

—Sam

On Tue, Jul 14, 2020, at 08:32, Drew DeVault wrote:
> Also, after you merge or rebase commits from your feature branch to
> master, their hash changes. So now we're deep comparing commits, and
> we have to store the full patch somewhere instead of just the sha to
> know that we've already built it.
>

-- 
Sam Whited
Reply to thread Export thread (mbox)