For example, the following build failed because of what seems to be a 
sr.ht error:

	https://builds.sr.ht/~admicos/job/477851

I resubmitted the build from the button next to it, and it created this 
new job:

	https://builds.sr.ht/~admicos/job/477853

However, the second build is not listed under the same "project" as the 
first, which makes it hard to find:

	https://builds.sr.ht/~admicos/moonlander

I would expect the successful build to be listed next to the failed 
build since both are from same manifest. Is this intended?

This is intended, yes. Resubmitting builds is not intended for "fixing"
whatever problem you had, it's a feature for debugging and ad-hoc builds.
You should commit a proper fix upstream if you want to associate it
with, well, the upstream project.

On 4/5/21 3:41 PM, Drew DeVault wrote:
> This is intended, yes. 

Thanks for the clarification.

> 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

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.

On Mon Apr 5, 2021 at 6:15 PM EDT, Devan Carpenter wrote:
> 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.

That your build's results can be affected by external factors is a sign
that your build is insufficiently hermetic. A similar error would be
non-determinism. In either case, it is a problem that should be
corrected, and so long as the problem exists, the failing build status
is quite an apt signal that such a problem is indeed present.

This is not always the case though.

https://builds.sr.ht/~tristan957/job/475977

For instance as well as the rest of the builds from that day.

The alpine/edge image pretty obviously had problems that were
outside of my control, but if I go to resubmit, it would make sense
to associate the build with the build history of the repo. Because
in the event that the alpine/edge image starts working again, I don't
have to push up a dummy commit to get my build status back to green,
when in reality, I should just be able to resubmit the build.

On Mon Apr 5, 2021 at 6:42 PM EDT, Tristan Partin wrote:
> This is not always the case though.
>
> https://builds.sr.ht/~tristan957/job/475977
>
> For instance as well as the rest of the builds from that day.
>
> The alpine/edge image pretty obviously had problems that were
> outside of my control, but if I go to resubmit, it would make sense
> to associate the build with the build history of the repo. Because
> in the event that the alpine/edge image starts working again, I don't
> have to push up a dummy commit to get my build status back to green,
> when in reality, I should just be able to resubmit the build.

There was an actual bug here, in this case with Alpine. The build status
reflects that. Bugs in your dependencies ultimately become bugs in your
software.

Alternatively, just don't obsess about the status badge?

This really has nothing to do with my non-existsent obsession about
a status badge.

Say my pipeline publishes something to PyPI. I should be able to
take the release from PyPI, see what git tag was associated with it,
and look up the pipeline associated with that release easily. In the
case of the alpine build I presented in my last email, because of the
resubmit, people would not easily be able to associate the tag with
the specific build pipeline that published the Python package. That
pipeline would just be orphaned forever.