Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
actions: build manuals #88488
Continued from #87853
This action will only start if something in
Each job will skip the cachix action/building the manual unless its paths have changed.
They could be split further into one action per path if we really wanted to save a couple of seconds.
The outcome of the doc format RFC could mean that this isn't needed in a few months which might actually be a point in its favour as it can be easily dropped.
I'm assuming that adding these builds to
I like it too. I don’t think this is a good idea, because they will fail during mass rebuilds from being too big. We don’t want to train users that red X’s can be ignored.…
On Fri, May 22, 2020, at 4:37 AM, Jörg Thalheim wrote: I also like github workflows for these sort of task more since they don't involve writing Rust and are easier to prototype. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#88488 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAASXLFVZ4WSWUWFLFM2KYTRSY2U3ANCNFSM4NGTPPUA>.
cross-posted from #87853:
I would like to revert this PR and close #88488. Not because I don't like github actions or feel like my pet project ofborg is threatened, but because I think these checks are actually harming the clearness of the checks. I'll explain:
The editorconfig check puts a big green check next to a commit, and hides the list of checks which passed. If ofborg is down or behind, it is likely people will think ofborg has approved the PR before it did. This could cause, well, all the problems ofborg is there to prevent.
The concrete problem here is this green check appears very early and is misleading, and there is no poka yoke to help people do the right thing.
One fear of #88488 is that it will introduce red X's if it takes a long time to build the manual, or something in the target branch is failing to build. This is reminiscent of the Travis times for me: Travis gave out so few green checkmarks, that if Travis gave a PR a green check-mark, it inspired more "okay what is broken that let travis pass it?" than "okay good to merge".
The goal of ofborg, and ever since ofborg became a thing, the "rule" has been green checkmark -> good to merge and red X -> don't merge.
The editorconfig check errodes the clearness of the green checkmark signal.
The big-rebuild failures we'll certainly have with #88488 errodes the clearness of the red X signal.
The clearness of this signal has been my guiding light on the design of ofborg for years now, and I am very afraid of threatening it.
A few suggestions that have been brought up to improve this:
That makes me think that, today, we should be undoing this check and closing #88488.