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

- [x] closes #41101
- [x] tests added / passed
- [x] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing.html#code-standards) for how to run them


Labels:
name: CI
description: Continuous Integration

Comments:
@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 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 :sweat_smile:

> 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 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 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:)

https://github.com/ShaharNaveh/pandas/pull/1
https://github.com/ShaharNaveh/pandas/pull/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](https://github.com/ShaharNaveh/pandas/pull/1)
> [ShaharNaveh#2](https://github.com/ShaharNaveh/pandas/pull/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](https://github.com/ShaharNaveh/pandas/pull/1)
> [ShaharNaveh#2](https://github.com/ShaharNaveh/pandas/pull/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)
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 
@ShaharNaveh do you have time to address the last comments please? Thanks!
> @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 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.