Closed willruggiano closed 2 weeks ago
It's basically this:
https://github.com/willruggiano/vscode-js-debug.nix/blob/main/.github/workflows/update-sources.yaml
(except nix flake update
instead of whatever this does)
I ran hercules-ci for a personal project and it's cool if you own the server. I haven't checked how it's done currently but with @Kranzes wanting to step down (did I get that right ?), it might be better to run the CI on an infrastructure more broadly accessible so I would favor github actions. But let's hear from the one who put this in place @Kranzes
I put Hercules-CI initially because it was the only way for us to get Darwin support working back them buildbot didn't exist at that tine. Also Hercules-CI allowed me to not need to write any annoying GHA yaml. I can suggest converting the project to use buildbot and GHA (for updating the flake every day, in a separate auto-merging PR, IF CI is green, I know that there are a couple of pre-made actions for that)
I know that there are a couple of pre-made actions for that)
Here is what we are using for Nixvim: https://github.com/nix-community/nixvim/blob/main/.github/workflows/update.yml
We can close this then @willruggiano ?
Yep. Can we remove the neovim-developer package from the checks? Honestly I'm not sure we should even have any checks related to whether neovim builds or not, not really our purview.
Honestly I'm not sure we should even have any checks related to whether neovim builds or not, not really our purview.
Well, I am not sure to agree there. As we override the derivation, a potential failure could be caused by our implementation.
Sure, that is fair. So just build the main neovim package then. I'm just saying that CI shouldn't fail because the neovim-developer package fails to build.
yeah neovim-developr was mostly for my convenience, in the hope it could help people wanting to develop for neovim. But it shouldn't block the pipelines.
As for merging failed updates, I am fine with both. I beleive consumers of the flake would prefer if the pipeline remained green at all time, even if it means not using the LATEST neovim. But then arises the question: who is going to fix nightly ? I have proven I could not be trusted with that so most likely it will be this repo maintainers or consumers who realize they are using an old neovim
Yeah that's what I'm here for 😄
As for the pipeline being "green", and again this is my own opinion, but the only required check should be that the flake evaluates. Whether neovim builds is not really our concern. The SLA, so to speak, of this repository should not exceed that of upstream: there's no guarantee it builds, or even works.
yeah neovim-developr was mostly for my convenience, in the hope it could help people wanting to develop for neovim. But it shouldn't block the pipelines.
neovim-developer is already disabled in the CI (not part of the checks
and has ignoreFailure = true
for H-CI).
Maybe you want to also exclude neovim-debug
? (although it does build fine)
Not sure why the PR checks are failing then. The only failed builds in those runs are the neovim-developer builds...
Not sure why the PR checks are failing then. The only failed builds in those runs are the neovim-developer builds...
Yes, this is weird...
I think the original issue is solved. Can we close this @willruggiano ?
I don't know who set up hercules ci, nor do I know how it works... anyone got anything? @teto @GaetanLepage
Also, would anyone care if I moved it to github actions? :)