Does anybody know if Sourcehut has support for/implements a system where
it is possible to ensure that the primary branch of the repository of
the system will never fail the tests (provided they are deterministic)?
For example, something like the one Rust uses (called bors):
https://graydon2.dreamwidth.org/1597.html
--
Kind regards,
Teymour
On Fri Aug 5, 2022 at 12:53 PM +0800, Teymour Aldridge wrote:
> Does anybody know if Sourcehut has support for/implements> a system where it is possible to ensure that the primary branch> of the repository of the system will never fail the tests> (provided they are deterministic)?>> For example, something like the one Rust uses (called bors): > https://graydon2.dreamwidth.org/1597.html
I don't think so, at least it is not documented.
> It gave us peace of mind (customers only pulled from that repository,> so never saw breakage)
Users/downstream should not pull from development branches,
but tagged releases. You can have a branch pointing to
the latest release if VCS is preferred over tarballs.
> important secondary benefit that engineers> could do their day's work from known-good revisions
If a team consists of multiple engineers, patches should be reviewed
(including tested) before applied. If you fear human errors,
you can set up a CI pushing to the never-fail branch upon success.
TBH though I would worry more about test coverage and flakiness instead.
> Users/downstream should not pull from development branches,> but tagged releases. You can have a branch pointing to> the latest release if VCS is preferred over tarballs.
The idea is to not have "development" branches - instead any commits
which are merged into the main branch should be of sufficient quality to
be deployed. Effectively this is a system of continuous delivery. This
is not uncommon, either; many web services have their servers configured
to automatically pull, build and deploy the latest commits from the main
branch. Another such system is described in
https://www.youtube.com/watch?v=tISy7EJQPzI.
> If a team consists of multiple engineers, patches should be reviewed> (including tested) before applied. If you fear human errors,> you can set up a CI pushing to the never-fail branch upon success.
This is exactly the idea of the system; patches should be tested before
being applied, and the version of the patch when merged into the main
branch should be tested (not the patch before it is merged). For a more
detailed (and short) explanation of this,
https://bors.tech/essay/2017/02/02/pitch/ is worth a read.
> TBH though I would worry more about test coverage and flakiness instead.
This system does require that the test suite is extensive. These issues
are present in either universe, however. Further, in my view, test
flakiness (where the tests fail sporadically) _is_ a bug; unfortunately
it is a bug which cannot be deterministically reproduced (which is why
it is essential to control in a careful and thorough manner any
nondeterminism introduced to a software system).
--
Kind regards,
Teymour
On Fri Aug 5, 2022 at 8:57 AM CEST, Teymour Aldridge wrote:
> The idea is to not have "development" branches - instead any commits > which are merged into the main branch should be of sufficient quality to > be deployed. Effectively this is a system of continuous delivery. This > is not uncommon, either; many web services have their servers configured > to automatically pull, build and deploy the latest commits from the main > branch. Another such system is described in > https://www.youtube.com/watch?v=tISy7EJQPzI.
I believe this would be trivial to implement by simply expanding the
existing CI pipelines[0] to run tests; the debate on whether unit tests
are worth it is a beehive I do not intend to poke though.
> (which is why it is essential to control in a careful and thorough> manner any nondeterminism introduced to a software system).
I think you're preaching to the choir with this :)
[0]: https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches/33251
--
Moritz Poldrack
https://moritz.sh