feat: setup nightly flow

[melMass]

Text for the squash merge:

---

reworks the CI logic a bit and introduces the idea of the nightly branch.

execution of the CI

• ci.yml will trigger as usual
  • it won't run when changes are made to *.md files only
  • it will trigger on all PRs and pushes to main and nightly
  • it will run nupm-tests.yml
  • install Nupm with a new custom actions/setup_nupm main will use a pinned version (0.87 for now), nightly.... nightly.
  • run the tests of the module
• in parallel, check_nightly.yml will make sure that PRs on main can be safely merged into nightly
• finally, only when a PR on main is closed, the new main branch will be merged into nightly

---

TODO

• [x] a dedicated action for setup_nupm, could be used in other jobs later.
• [x] on pushes in PRs targeting main a new step is checked mergeable in nightly
• [x] on merge of PRs targeting main, main is automatically merged to nightly.

[melMass]

Mmm for some reason it doesn't run the CI 🤣

[amtoine]

Important the few force-pushes above were solely to make my pure-refactoring changes fit into one commit :wink:

[melMass]

Important I reverted "make the tests manually triggerable" since it will be once merged I believe (and it broke the CI)

[melMass]

There is just one thing we need to do before merge btw! (Add write rights for now push will fail)

[amtoine]

There is just one thing we need to do before merge btw! (Add write rights for now push will fail)

okey, you wanna do that?

there is a single thread missing, i don't know the syntax nor where to search for documentation for it :eyes:

[melMass]

It's just a matter of using the builtin GitHub token I think, I will give it a quick look tonight

[amtoine]

i thought using actions/checkout@v3 and setting up Git's user.name and user.email were enough to allow the CI to push to the repo :open_mouth:

[amtoine]

this CI pushes directly to the repo and i never setup any token in my entire life :wink:

[melMass]

i thought using actions/checkout@v3 and setting up Git's user.name and user.email were enough to allow the CI to push to the repo 😮

That would be insanely insecure.

this CI pushes directly to the repo and i never setup any token in my entire life 😉

This means you enable read and write for all actions. That's not a big deal if you are only using "local" (from the repo) actions and workflows but can be dangerous (theoricaly) otherwise, more info here: https://docs.github.com/en/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token

Maybe we can just enable it globally you decide

[amtoine]

i now see what you mean @melMass and completely forgot i had to turn that on for nu-criterion-tracker :eyes:

should i tick Read and write permissions in the menu below in > settings > actions > Workflow permissions?

[melMass]

should i tick Read and write permissions in the menu below in > settings > actions > Workflow permissions?

That would work, or setting just the permissions on the specific action that requires it. I just quickly checked I might have been too paranoid, there is no real issue in our case for making it global, unless we start relying on a lesser known external action.

I think the attack vectors are mostly that and script injection, the later should be covered by our action encapsulation

[amtoine]

okey let's keep that simple for now then :relieved:

i've turned on Read and write permissions :+1:

[amtoine]

Note i've left the commits above (from 71168be to b3b7ac8 included) to show that i couldn't get https://github.com/amtoine/nu-git-manager/pull/82#discussion_r1394598252 to work :cry:

[amtoine]

Note same here, the last two commits are a failed attempt to apply https://github.com/actions/runner/issues/409#issuecomment-752775072