One trick to make your life much better as a maintainer and help contributors
Have a Makefile directive to run everything that runs on CI
`make x` is all it should take to verify the changes pass automated tests
Linter, formatter, sorter, unit tests, etc
If tooling is needed then add a `make setup` directive that takes care of installing it
#offlinefirst #ci #development #git #GitHub #GitLab #Codeberg #dx #FreeSoftware #FLOSS #developerExperience #developer
Jeffrey Bouter
in reply to Sonny • • •Sonny
in reply to Jeffrey Bouter • • •Avoid multiple "fixup" commits to fix CI issues one after the other.
=
Reduce email notifications
Reduced "please rebase"
Less friction for contributors
Less wasted time
Philn
in reply to Sonny • • •GitHub - casey/just: 🤖 Just a command runner
GitHubSonny
in reply to Philn • • •no strong opinion as long as the project has a clear `do this to get started'
But make is everywhere 🤷
Philn
in reply to Sonny • • •almost, iirc it's not in Silverblue ;)
Anyway yes, I understand your point :)
Julien W.
in reply to Sonny • • •+ "npm run fix-all" for all the linter autofixable issues.
Dimitri Merejkowsky
in reply to Julien W. • • •@julienw
> Avoid multiple "fixup" commits to fix CI issues one after the other.
> Reduced "please rebase"
An other way to avoid that - just merge the PR as-is (event if the CI fails) - and then make a commit to fix things up
If you're a maintainer and your goal is to gain contributors, this is a much better technique IMHO
Chances are, you were the one who set up the CI, so you'll be much faster than a first-time contributor
Sonny
in reply to Dimitri Merejkowsky • • •Squash merge is the way to go if you're unhappy with the commits of a branch 👍
But fixing the CI isn't necessarily trivial.
I do resort to doing small fixes before merging contributions, specially for first time contributors.
Julien W.
in reply to Sonny • • •f♯ a♯ ∞
in reply to Sonny • • •@nicosomb