p53209761
/
test_ok2
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge pull request #8462 from RonnyPfannschmidt/main_fixup_followup 

port the rest of the scripts/docs over to the main branch
This commit is contained in:
Ronny Pfannschmidt 2021-03-27 15:49:20 +01:00 committed by GitHub
parent c1bdff9e69 ff6d5ae278
commit 9052a9e313
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
7 changed files with 27 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
CHANGELOG.rst
View File

@ -4,4 +4,4 @@ Changelog
The pytest CHANGELOG is located `here <https://docs.pytest.org/en/stable/changelog.html>`__.
The source document can be found at: https://github.com/pytest-dev/pytest/blob/master/doc/en/changelog.rst
The source document can be found at: https://github.com/pytest-dev/pytest/blob/main/doc/en/changelog.rst

16
CONTRIBUTING.rst
View File

@ -234,7 +234,7 @@ Here is a simple overview, with pytest-specific bits:
$ git clone git@github.com:YOUR_GITHUB_USERNAME/pytest.git
$ cd pytest
# now, create your own branch off "master":
# now, create your own branch off "main":
$ git checkout -b your-bugfix-branch-name main
@ -387,15 +387,15 @@ Suppose for example that the latest release was 1.2.3, and you want to include
a bug fix in 1.2.4 (check https://github.com/pytest-dev/pytest/releases for the
actual latest release). The procedure for this is:
#. First, make sure the bug is fixed the ``master`` branch, with a regular pull
#. First, make sure the bug is fixed the ``main`` branch, with a regular pull
request, as described above. An exception to this is if the bug fix is not
applicable to ``master`` anymore.
applicable to ``main`` anymore.
#. ``git checkout origin/1.2.x -b backport-XXXX`` # use the master PR number here
#. ``git checkout origin/1.2.x -b backport-XXXX`` # use the main PR number here
#. Locate the merge commit on the PR, in the *merged* message, for example:
nicoddemus merged commit 0f8b462 into pytest-dev:master
nicoddemus merged commit 0f8b462 into pytest-dev:main
#. ``git cherry-pick -x -m1 REVISION`` # use the revision you found above (``0f8b462``).
@ -408,7 +408,7 @@ actual latest release). The procedure for this is:
Who does the backporting
~~~~~~~~~~~~~~~~~~~~~~~~
As mentioned above, bugs should first be fixed on ``master`` (except in rare occasions
As mentioned above, bugs should first be fixed on ``main`` (except in rare occasions
that a bug only happens in a previous release). So who should do the backport procedure described
above?
@ -417,8 +417,8 @@ above?
2. However, often the merge is done by another maintainer, in which case it is nice of them to
do the backport procedure if they have the time.
3. For bugs submitted by non-maintainers, it is expected that a core developer will to do
the backport, normally the one that merged the PR on ``master``.
4. If a non-maintainers notices a bug which is fixed on ``master`` but has not been backported
the backport, normally the one that merged the PR on ``main``.
4. If a non-maintainers notices a bug which is fixed on ``main`` but has not been backported
(due to maintainers forgetting to apply the *needs backport* label, or just plain missing it),
they are also welcome to open a PR with the backport. The procedure is simple and really
helps with the maintenance of the project.

2
README.rst
View File

@ -24,7 +24,7 @@
:target: https://github.com/pytest-dev/pytest/actions?query=workflow%3Amain
.. image:: https://results.pre-commit.ci/badge/github/pytest-dev/pytest/main.svg
:target: https://results.pre-commit.ci/latest/github/pytest-dev/pytest/master
:target: https://results.pre-commit.ci/latest/github/pytest-dev/pytest/main
:alt: pre-commit.ci status
.. image:: https://img.shields.io/badge/code%20style-black-000000.svg

20
RELEASING.rst
View File

@ -32,10 +32,10 @@ and notify it as a comment in the issue.
Minor releases
^^^^^^^^^^^^^^
1. Create a new maintenance branch from ``master``::
1. Create a new maintenance branch from ``main``::
git fetch --all
git branch 5.2.x upstream/master
git branch 5.2.x upstream/main
git push upstream 5.2.x
2. Open a new issue and add this comment to the body::
@ -48,10 +48,10 @@ notify it as a comment in the issue.
Major and release candidates
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1. Create a new maintenance branch from ``master``::
1. Create a new maintenance branch from ``main``::
git fetch --all
git branch 6.0.x upstream/master
git branch 6.0.x upstream/main
git push upstream 6.0.x
2. For a **major release**, open a new issue and add this comment in the body::
@ -66,7 +66,7 @@ The automated workflow will publish a PR for a branch ``release-6.0.0`` and
notify it as a comment in the issue.
At this point on, this follows the same workflow as other maintenance branches: bug-fixes are merged
into ``master`` and ported back to the maintenance branch, even for release candidates.
into ``main`` and ported back to the maintenance branch, even for release candidates.
**A note about release candidates**
@ -83,7 +83,7 @@ to be executed on that platform.
To release a version ``MAJOR.MINOR.PATCH``, follow these steps:
#. For major and minor releases, create a new branch ``MAJOR.MINOR.x`` from
``upstream/master`` and push it to ``upstream``.
``upstream/main`` and push it to ``upstream``.
#. Create a branch ``release-MAJOR.MINOR.PATCH`` from the ``MAJOR.MINOR.x`` branch.
@ -114,18 +114,18 @@ Both automatic and manual processes described above follow the same steps from t
#. Merge the PR.
#. Cherry-pick the CHANGELOG / announce files to the ``master`` branch::
#. Cherry-pick the CHANGELOG / announce files to the ``main`` branch::
git fetch --all --prune
git checkout origin/master -b cherry-pick-release
git checkout origin/main -b cherry-pick-release
git cherry-pick -x -m1 upstream/MAJOR.MINOR.x
#. Open a PR for ``cherry-pick-release`` and merge it once CI passes. No need to wait for approvals if there were no conflicts on the previous step.
#. For major and minor releases, tag the release cherry-pick merge commit in master with
#. For major and minor releases, tag the release cherry-pick merge commit in main with
a dev tag for the next feature release::
git checkout master
git checkout main
git pull
git tag MAJOR.{MINOR+1}.0.dev0
git push git@github.com:pytest-dev/pytest.git MAJOR.{MINOR+1}.0.dev0

2
scripts/prepare-release-pr.py
View File

@ -3,7 +3,7 @@ This script is part of the pytest release process which is triggered manually in
tab of the repository.
The user will need to enter the base branch to start the release from (for example
``6.1.x`` or ``master``) and if it should be a major release.
``6.1.x`` or ``main``) and if it should be a major release.
The appropriate version will be obtained based on the given branch automatically.

10
scripts/release-on-comment.py
View File

@ -3,7 +3,7 @@ This script is part of the pytest release process which is triggered by comments
in issues.
This script is started by the `release-on-comment.yml` workflow, which always executes on
`master` and is triggered by two comment related events:
`main` and is triggered by two comment related events:
* https://help.github.com/en/actions/reference/events-that-trigger-workflows#issue-comment-event-issue_comment
* https://help.github.com/en/actions/reference/events-that-trigger-workflows#issues-event-issues
@ -16,8 +16,8 @@ The payload must contain a comment with a phrase matching this pseudo-regular ex
Then the appropriate version will be obtained based on the given branch name:
* a major release from master if "major" appears in the phrase in that position
* a feature or bug fix release from master (based if there are features in the current changelog
* a major release from main if "major" appears in the phrase in that position
* a feature or bug fix release from main (based if there are features in the current changelog
folder)
* a bug fix from a maintenance branch
@ -230,11 +230,11 @@ def find_next_version(base_branch: str, is_major: bool) -> str:
breaking = list(changelog.glob("*.breaking.rst"))
is_feature_release = features or breaking
if is_feature_release and base_branch != "master":
if is_feature_release and base_branch != "main":
msg = dedent(
f"""
Found features or breaking changes in `{base_branch}`, and feature releases can only be
created from `master`:
created from `main`:
"""
)
msg += "\n".join(f"* `{x.name}`" for x in sorted(features + breaking))

2
src/_pytest/assertion/__init__.py
View File

@ -104,7 +104,7 @@ def install_importhook(config: Config) -> rewrite.AssertionRewritingHook:
def pytest_collection(session: "Session") -> None:
# This hook is only called when test modules are collected
# so for example not in the master process of pytest-xdist
# so for example not in the managing process of pytest-xdist
# (which does not collect test modules).
assertstate = session.config._store.get(assertstate_key, None)
if assertstate: