Add docs label for PRs that touch Doc/tools/.nitignore

[skirpichev]

See e.g. python/cpython#114280 or python/cpython#114194

[hugovk]

Good idea!

I found it a bit annoying the label is added for PRs touching rst files in Docs/, but not those touching rst plus .nitignore.

[skirpichev]

PR: #617

[ezio-melotti]

I found it a bit annoying the label is added for PRs touching rst files in Docs/, but not those touching rst plus .nitignore.

Why does this happen? Isn't bedevere already adding the docs label whenever at least an .rst file has been changed, regardless of the other files?

[skirpichev]

Looking in the sources, it doesn't add any labels (pr_labels == []) if there is some file, which doesn't match known patterns:

bedevere/bedevere/prtype.py

Lines 42 to 51 in b5bcd24

	for filename in filenames:
	if util.is_news_dir(filename):
	news = True
	filepath = pathlib.PurePath(filename)
	if filepath.suffix == ".rst":
	docs = True
	elif filepath.name.startswith("test_"):
	tests = True
	else:
	return pr_labels

Another case: #605

[ezio-melotti]

So the problem is the return (prematurely?) terminating the loop? Is that intentional?

[skirpichev]

Is that intentional?

I guess - so. Or every pr that has some *.rst file could skip news.

[AlexWaygood]

Is that intentional?

I guess - so. Or every pr that has some *.rst file could skip news.

That wouldn't be correct — there are lots of PRs that introduce new features and add docs for the new feature as part of the same PR. Most of those PRs need news entries.

[skirpichev]

(On another hand, most PRs, that touch only test files - probably could skip news;) That's another story, however.)

[ezio-melotti]

Ok, so the goal is to add the docs label only to PRs that are "docs-only", i.e. they only change documentation and possibly files related to the documentation (like .nitignore). If a PR adds a new feature and edits the docs to document it, it's not "docs-only" and shouldn't get the docs label.

(Maybe this should be spelled out clearly in a comment/docstring, including the expected behavior for other labels, since the intention is currently not too clear IMHO).