Actions are fine for very simple repos.
Gitlab CI is a dream, definitely my preference at work.
Jenkins can be okay or horrible depending on the setup.
What makes GitLab CI better than GitHub Actions in your eyes?
I’ve not extensively used either, and GitLab CI has been a while, but they felt pretty similar. I had put them into the same category.
We use Jenkins at work. I administrate it. For the most part, I find it horrendous.
Just self host an open source runner like woodpecker and you’ll never have to move again
hell you can even self host github actions via
actThis. As someone who migrated an organization’s repos from a self hosted Git server to GitHub (begrudgingly) and then back to a self hosted Git server again when it didn’t meet the business needs … emphatically this.
Do formatting and linting and such autofix issues automatically as part of pre-commit checks. That way they don’t end up as part of the CI.
You need them in CI anyway to check people have actually done that, but yeah you definitely don’t need to have CI automatically fix formatting and commit the fixes. That’s crazy.
No, you don’t.
To check if people have done what - committed? That’s the only thing they need to do, and they’ll stumble upon a roadblock immediately if the typecheck or lint fails.
Committing itself won’t be possible… That’s why we have automated pre-commit checks that don’t depend on people remembering to do them manually.
To check that people ran the pre-commit linters.
Committing itself won’t be possible
That’s not how pre-commit hooks work. They’re entirely optional and opt-in. You need CI to also run them to ensure people don’t forget.
They’re optional if you make them optional. I didn’t. You do as you please. 😄
No, they’re inherently optional in Git. There’s no way to “check in” a git hook. You have to put in your
READMEClone the repo and then please run
pre-commit install! Oh and whatever you do don’tgit commit --no-verify!You definitely need to actually check the lints in CI. It’s very easy though, just add
pre-commit run -ato your CI script.
Agreed. The idea of throwing code up at the CI and expecting it to fix my mistakes seems like a bad habit to me.
Yep, I’d say so too. The moment I read the part about formatting in the CI, I thought to myself: I don’t think GitHub Actions are the problem at hand. 😄
If it’s open source I’d still add it, because a lot of people can’t follow basic instructions.
They don’t have to follow anything except try to commit their changes. Won’t be possible even locally if linting or typechecking fail.
This is the way. I do my checks on pre push because my team has a PR driven workflow. I also have an alias to
run-tests && git push origin HEADsince my tests are expensive (minutes to run thousands of tests), and I didn’t want that in a git hook.
The only good thing about Github Actions is the “marketplace” or that you can publish and find actions. The rest is just… not the way I’d do CI. I’m so glad I don’t have to touch that anymore. Only thing worse than Github CI is Jenkins. *Shudder*
You like the marketplace? I dislike it. Or at least its form. I appreciate that there is sharing of actions.
But I dislike having to navigate between repo and marketplace pages. I dislike that I have to assess who publishes them and inspect whether they and the code are trustworthy, and I have to assess risk or whether to copy or extract the relevant code. (And then you have to add and configure via text and magic strings and look up params elsewhere which of course is a consequence of the tech, not a fault of the marketplace itself.)
I feel it adds so much indirection and diffusion it’s hard to do good trustworthy actions/code well. Which if course stands against it’s usefulness of sharing workflows and actions. I know I’m more concerned and more thorough with that stuff than most people.
I like the concept. It helps with not having to rewrite the same stuff over and over again. It’s like a package registry. Whether it’s implemented well is debatable of course and it’s understandable you don’t like it.
Github actions and docker containers. A match made in heck.
