CI: skip tests when only files in doc/web changes (github actions)

[ShaharNaveh]

• closes CI / DOC: skip tests when only files in doc/ is changed  #41101
• tests added / passed
• Ensure all linting tests pass, see here for how to run them

[jorisvandenbossche]

@ShaharNaveh Looking at the diff, I think this PR is making it so that we only do the doc biuld if anything in doc/** or web/** is touched, is that a correct understanding?

However, I think we actually want to other way around: we can skip the other (non-doc) builds if only doc/** is touched.

The doc build also needs to run if eg a docstring has changed in the actual pandas source.

[ShaharNaveh]

@ShaharNaveh Looking at the diff, I think this PR is making it so that we only do the doc biuld if anything in doc/** or web/** is touched, is that a correct understanding?

That's correct.

However, I think we actually want to other way around: we can skip the other (non-doc) builds if only doc/** is touched.

Oh my, I completly understood that wrong 😅

[datapythonista]

Looks good., just couple of things.

@jorisvandenbossche do you want to skip the tests in the master builds too? Feels like only skipping for PRs, and running full master builds can make sense too.

@ShaharNaveh do you think you can commit this in the master of your fork, and open a PR in your fork modifying the docs, and another modifying the docs and something else, and see if he builds run as expected? I think should be quite fast to set up, and we'll be on the right side, and avoid much disruption if we're missing something here. Thanks!

[jorisvandenbossche]

do you want to skip the tests in the master builds too? Feels like only skipping for PRs, and running full master builds can make sense too.

Yes, I think it would be good to only skip the tests on PRs when appropriate, and on master still always run the tests.

(this would mean removing the paths-ignore for the "push", and only keeping it for "pull_request")

[ShaharNaveh]

@ShaharNaveh do you think you can commit this in the master of your fork, and open a PR in your fork modifying the docs, and another modifying the docs and something else, and see if he builds run as expected? I think should be quite fast to set up, and we'll be on the right side, and avoid much disruption if we're missing something here. Thanks!

Sure:)

[ShaharNaveh]

@ShaharNaveh do you think you can commit this in the master of your fork, and open a PR in your fork modifying the docs, and another modifying the docs and something else, and see if he builds run as expected? I think should be quite fast to set up, and we'll be on the right side, and avoid much disruption if we're missing something here. Thanks!

Sure:)

ShaharNaveh#1
ShaharNaveh#2

[ShaharNaveh]

@ShaharNaveh do you think you can commit this in the master of your fork, and open a PR in your fork modifying the docs, and another modifying the docs and something else, and see if he builds run as expected? I think should be quite fast to set up, and we'll be on the right side, and avoid much disruption if we're missing something here. Thanks!

Sure:)

ShaharNaveh#1
ShaharNaveh#2

@ShaharNaveh do you think you can commit this in the master of your fork, and open a PR in your fork modifying the docs, and another modifying the docs and something else, and see if he builds run as expected? I think should be quite fast to set up, and we'll be on the right side, and avoid much disruption if we're missing something here. Thanks!

Sure:)

ShaharNaveh#1
ShaharNaveh#2

One thing that should be noted is that in PR#2 (Doc and Code changes) that the Azure pipeline does not trigger at all, but I think this is normal (I hope)

[jorisvandenbossche]

Thanks for testing it!

One thing that should be noted is that in PR#2 (Doc and Code changes) that the Azure pipeline does not trigger at all, but I think this is normal (I hope)

Yes, I think that is indeed to be expected, since AFAIK Azure Pipelines are not activated on forks

[datapythonista]

@ShaharNaveh do you have time to address the last comments please? Thanks!

[ShaharNaveh]

@ShaharNaveh do you have time to address the last comments please? Thanks!

I addressed those comments a while back, just forgot to mark them as "resolved".
Can you please review this PR again @jorisvandenbossche ?

[MarcoGorelli]

Great idea! Just got a comment

[MarcoGorelli]

Thanks @ShaharNaveh - this looks correct to me, and it can be easily reverted if there's any issues, so let's merge and see

[MarcoGorelli]

any reason why the other have doc/** and this one has doc/*?

[ShaharNaveh]

any reason why the other have doc/** and this one has doc/*?

Yes, because this is the "azure" CI, and the other files are related to the "github actions" CI.
I just copied the syntax from their examples in the docs, I haven't really tested the differences.

[MarcoGorelli]

Thanks @ShaharNaveh - this looks correct, and if it's not it's easy to revert, so let's merge

[simonjayhawkins]

@MarcoGorelli our release scripts work from master and not a commit hash. will try to push the tag to master but may fail. in that case will need to change the milestone on this and the other PR.