Reorganize GitHub Actions

[mwouts]

Thank you @matthewfeickert for your recommendations at #1037 !

I have tried to implement those in this PR. If you have a minute to have a look that would be great! Thank you.

[mwouts]

Well I'm not sure I am using concurrency in the right way. What I wanted to do with skip_duplicate was to not run the same actions twice when there is both a push and a pull_request event. Is that something one can avoid with concurrency? Or maybe I just need to append the step name to the concurrency group?

[mwouts]

Well if my understanding is correct, concurrency will ensure that I don't get two runs for the same action on the same branch, which is useful.

However I see duplicated runs on push and pull_request events:

To avoid these I will use the skip_duplicate action.

[codecov]

Codecov Report

Merging #1041 (dbdc841) into main (e097422) will decrease coverage by 0.04%.
The diff coverage is 100.00%.

❗ Current head dbdc841 differs from pull request most recent head ee2c0b5. Consider uploading reports for the commit ee2c0b5 to get more accurate results

@@            Coverage Diff             @@
##             main    #1041      +/-   ##
==========================================
- Coverage   99.02%   98.99%   -0.04%     
==========================================
  Files         119      119              
  Lines       11030    11030              
==========================================
- Hits        10923    10919       -4     
- Misses        107      111       +4     

Impacted Files	Coverage Δ
jupytext/version.py	100.00% <100.00%> (ø)
jupytext/__main__.py	0.00% <0.00%> (-100.00%)	⬇️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[mwouts]

I have removed the trigger on pull_request events as I could not find out how to skip duplicates among workflows. However, I am not sure what happens when someone opens a PR from a branch on a fork - will the workflow run at all? @matthewfeickert would you mind opening a PR from a fork of this branch, with an additional commit? Thank you!

[matthewfeickert]

👍 I'm traveling this week so won't have much time to look at this till maybe Tuesday.

[mwouts]

Sure this can wait! No hurry at all. And thanks for helping me with this!

[LecrisUT]

However, I am not sure what happens when someone opens a PR from a branch on a fork - will the workflow run at all?

This is up to the settings of the repo. By default someone has to approve the workflow before it runs. The PR author can always make a PR on their own forks to run the jobs though

[LecrisUT]

Well if my understanding is correct, concurrency will ensure that I don't get two runs for the same action on the same branch, which is useful.

However I see duplicated runs on push and pull_request events:

To avoid these I will use the skip_duplicate action.

I think you had it right on that commit. The issue is that the previous commit did noy have the concurrency on the root so those two actions were incompatible so it didn't have the predicted effect

[LecrisUT]

Hope the code review helps. I can't review the codeql part because I'm not familiar with it. But shouldn't it be in the CI?

[LecrisUT]

Same trigger as above

[mwouts]

I see. At #1084 I have keep everything in the same file for now.

[LecrisUT]

What's the deal with this test? It should be in the CI.

But beware that distro pacakagers rely on the fact that sdist is a superset of git archive. Of course you can remove files like .github, but consult with a distro packager to be safe. E.g. the maintainers of python3-jupytext on fedora. I can do a quick lookover if you point me to the sdist ignore list.

[mwouts]

I agree that this belongs to the CI.

I am not sure I am following your second comment, sorry. This file: MANIFEST.in controls what goes into the package.

[LecrisUT]

My reading of that check was so that you make sure that large filea are not being packaged right? Well about that, they should be packaged because distro maintainers expect that all relevant files are available on PyPI as well as other generated files.

[mwouts]

Thank you @LecrisUT for your comments. Very helpful. It might take me some time to address them all but I'll surely try.

[mwouts]

Closed in favor of #1084