Since haskell/hackage-server#1469
(Check candidate uploads against main index), Hackage no longer allows
candidates for published versions.

But we use the `.ci/publish_sdist.sh` script from our stable branches to
publish a candidate before we do the final release, so we do want it to
run for nightlies on our stable branch. But we need to differentiate between
runs that do not contain a new version and runs that do contain a new
version.

So we do this check in the CI job, and exit with a special exit code to
flag when we did not upload a candidate. This means normal nightlies
will have an exclamation mark in an orange circle next to the
`hackage-release-candidate`, indicating a failure that does not cause
the pipeline as a whole to fail.

When the "special" nightly before a release is run, the developer
inspecting the result should verify a candidate was published (check
mark in green circle). In the usual case, where only one candidate will
be uploaded before release, they will also necessarily notice that the
candidate is simply not on Hackage if they forget to check the CI job's
result.

Because we don't have control over the exit codes of any binaries we
invoke, a trap handler is added in `.ci/functions.sh` that makes sure no
other exits will have the exit code we reserve for allowed-to-fail.
Currently, GitLab runners will not actually propagate the exit code of a
failing step in the script, but this might very well change in an
update. So we also proof our `.ci/setup.sh` script against such exits so
they don't trigger unwantedly in the `hackage-release-candidate` job.

Since haskell/hackage-server#1469
(Check candidate uploads against main index), Hackage no longer allows
candidates for published versions.

But we use the `.ci/publish_sdist.sh` script from our stable branches to
publish a candidate before we do the final release, so we do want it to
run for nightlies on our stable branch. But we need to differentiate between
runs that do not contain a new version and runs that do contain a new
version.

So we do this check in the CI job, and exit with a special exit code to
flag when we did not upload a candidate. This means normal nightlies
will have an exclamation mark in an orange circle next to the
`hackage-release-candidate`, indicating a failure that does not cause
the pipeline as a whole to fail.

When the "special" nightly before a release is run, the developer
inspecting the result should verify a candidate was published (check
mark in green circle). In the usual case, where only one candidate will
be uploaded before release, they will also necessarily notice that the
candidate is simply not on Hackage if they forget to check the CI job's
result.

Because we don't have control over the exit codes of any binaries we
invoke, a trap handler is added in `.ci/functions.sh` that makes sure no
other exits will have the exit code we reserve for allowed-to-fail.
Currently, GitLab runners will not actually propagate the exit code of a
failing step in the script, but this might very well change in an
update. So we also proof our `.ci/setup.sh` script against such exits so
they don't trigger unwantedly in the `hackage-release-candidate` job.

Since haskell/hackage-server#1469
(Check candidate uploads against main index), Hackage no longer allows
candidates for published versions.

But we use the `.ci/publish_sdist.sh` script from our stable branches to
publish a candidate before we do the final release, so we do want it to
run for nightlies on our stable branch. But we need to differentiate between
runs that do not contain a new version and runs that do contain a new
version.

So we do this check in the CI job, and exit with a special exit code to
flag when we did not upload a candidate. This means normal nightlies
will have an exclamation mark in an orange circle next to the
`hackage-release-candidate`, indicating a failure that does not cause
the pipeline as a whole to fail.

When the "special" nightly before a release is run, the developer
inspecting the result should verify a candidate was published (check
mark in green circle). In the usual case, where only one candidate will
be uploaded before release, they will also necessarily notice that the
candidate is simply not on Hackage if they forget to check the CI job's
result.

Because we don't have control over the exit codes of any binaries we
invoke, a trap handler is added in `.ci/functions.sh` that makes sure no
other exits will have the exit code we reserve for allowed-to-fail.
Currently, GitLab runners will not actually propagate the exit code of a
failing step in the script, but this might very well change in an
update. So we also proof our `.ci/setup.sh` script against such exits so
they don't trigger unwantedly in the `hackage-release-candidate` job.

Since haskell/hackage-server#1469
(Check candidate uploads against main index), Hackage no longer allows
candidates for published versions.

But we use the `.ci/publish_sdist.sh` script from our stable branches to
publish a candidate before we do the final release, so we do want it to
run for nightlies on our stable branch. But we need to differentiate between
runs that do not contain a new version and runs that do contain a new
version.

So we do this check in the CI job, and exit with a special exit code to
flag when we did not upload a candidate. This means normal nightlies
will have an exclamation mark in an orange circle next to the
`hackage-release-candidate`, indicating a failure that does not cause
the pipeline as a whole to fail.

When the "special" nightly before a release is run, the developer
inspecting the result should verify a candidate was published (check
mark in green circle). In the usual case, where only one candidate will
be uploaded before release, they will also necessarily notice that the
candidate is simply not on Hackage if they forget to check the CI job's
result.

Because we don't have control over the exit codes of any binaries we
invoke, a trap handler is added in `.ci/functions.sh` that makes sure no
other exits will have the exit code we reserve for allowed-to-fail.
Currently, GitLab runners will not actually propagate the exit code of a
failing step in the script, but this might very well change in an
update. So we also proof our `.ci/setup.sh` script against such exits so
they don't trigger unwantedly in the `hackage-release-candidate` job.

(cherry picked from commit 7aef241)

Since haskell/hackage-server#1469
(Check candidate uploads against main index), Hackage no longer allows
candidates for published versions.

But we use the `.ci/publish_sdist.sh` script from our stable branches to
publish a candidate before we do the final release, so we do want it to
run for nightlies on our stable branch. But we need to differentiate between
runs that do not contain a new version and runs that do contain a new
version.

So we do this check in the CI job, and exit with a special exit code to
flag when we did not upload a candidate. This means normal nightlies
will have an exclamation mark in an orange circle next to the
`hackage-release-candidate`, indicating a failure that does not cause
the pipeline as a whole to fail.

When the "special" nightly before a release is run, the developer
inspecting the result should verify a candidate was published (check
mark in green circle). In the usual case, where only one candidate will
be uploaded before release, they will also necessarily notice that the
candidate is simply not on Hackage if they forget to check the CI job's
result.

Because we don't have control over the exit codes of any binaries we
invoke, a trap handler is added in `.ci/functions.sh` that makes sure no
other exits will have the exit code we reserve for allowed-to-fail.
Currently, GitLab runners will not actually propagate the exit code of a
failing step in the script, but this might very well change in an
update. So we also proof our `.ci/setup.sh` script against such exits so
they don't trigger unwantedly in the `hackage-release-candidate` job.

(cherry picked from commit 7aef241)

Co-authored-by: Peter Lebbing <peter@digitalbrains.com>