Making mergifyLabelPaths overridable

[TonioGela]

Closes #220.

[TonioGela]

Hmm, running mergifyGenerate annihilates .mergify.yml, so the pr logic is probably wrong 👉 👈

[bpholt]

Hmm, running mergifyGenerate annihilates .mergify.yml, so the pr logic is probably wrong 👉 👈

I wonder if we ought to have some scripted tests for things like this, to show that the generated file is correct in different scenarios. (Not that you have to add that to this PR if you don't want to, just that it might be helpful if you did.)

[TonioGela]

I don't have that much experience with scripted tests if not in g8 templates, but AFAIK, the series/0.5 has some tests I might take inspiration from, I'll check and add them

[armanbilge]

Yes, we really ought to have tests in general. I've been lazy to do so, partly because testing generated output can become annoying. See some discussion in #26.

For this specific one, we can use a dog-food: override mergifyLabelPaths in build.sbt, just to prove we can. For example you should be able to remove this useless label.

• sbt-typelevel/.mergify.yml

  Lines 156 to 163 in abc217d

  	- name: Label unidoc PRs
  	conditions:
  	- files~=^unidoc/
  	actions:
  	label:
  	add:
  	- unidoc
  	remove: []

[armanbilge]

Happy to close this one, finally! This was a good exercise in sbt setting evaluation and scoping 🤓

[TonioGela]

For this specific one, we can use a dog-food: override mergifyLabelPaths in build.sbt, just to prove we can. For example you should be able to remove this useless label.

I did it and it might act as a test as you said. For what concerns #26, probably the better thing is to implement them in a separate PR, innit?