Date: Mon, 5 Apr 2021 23:15:45 +0100
From: Devan Carpenter <mail@dvn.me>
To: Ecmel Berk =?utf-8?Q?Canl=C4=B1er?= <me@ecmelberk.com>
Cc: Drew DeVault <sir@cmpwn.com>, ~sircmpwn/sr.ht-discuss@lists.sr.ht
Subject: Re: [builds.sr.ht] Resubmitted builds are not associated with
 original build's project
Message-ID: <20210405221545.vhbvbjnrlonbsu2u@iyo>
References: <34f77392-19fa-5104-736f-10293d857642@ecmelberk.com>
 <CAFSQFE3NRPZ.WR89A2RXMNDE@taiga>
 <b9bb10a1-b85b-d07f-acfe-f3c2dc2783d1@ecmelberk.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <b9bb10a1-b85b-d07f-acfe-f3c2dc2783d1@ecmelberk.com>

Ecmel Berk Canlıer transcribed some bytes:
> > You should commit a proper fix upstream if you want to associate it
> > with, well, the upstream project.
> 
> Well, the issue with the build[1] wasn't caused by an upstream change,
> though. That's why I resubmitted the build instead of committing something
> upstream.
> 
> 1: see task "setup" line 3

Yea, the intention does not line up with the actual useage, from my
point of view. You can see that other CI systems, like Gitlab CI, handle
this the opposite way. If you re-run a build manually then it will
supercede the previous build status in the UI. This is different than
running an "ad-hoc" build by uploading an arbitrary manifest.

It makes sense because of situations exactly like what Ecmel ran into.
The *external environment* was the source of the error, not something in
their repo. Re-running the build _is_ the proper fix in this case.