pytest-dev/meta

Used for generic pytest organization issues, stuff that can impact multiple projects.

meta's Issues

enable gitter.im "bridge" to libera IRC

There's already a gitter.im room at https://gitter.im/pytest-dev/pytest and a libera room at https://matrix.to/#/#pytest:libera.chat (Internal room ID: !ipBocKVYhzwSPWzCKM:libera.chat)

I just need to send an email like:

MIME-Version: 1.0
Date: Fri, 13 Aug 2021 14:43:53 +0100
Message-ID: <[email protected]>
Subject: merging the pytest libera and gitter chat rooms
From: Thomas Grainger <[email protected]>
To: [email protected]
Content-Type: text/plain; charset="UTF-8"

please could you merge !ipBocKVYhzwSPWzCKM:libera.chat with
https://gitter.im/pytest-dev/pytest and configure a tombstone/redirect
per https://github.com/pytest-dev/meta/issues/10

thanks

Thomas Grainger

Simplify plugin adoption guidelines (github repository transfer)

The current documented process for transferring a plugin under pytest-dev is quite complex and it does work work wellbeing done offline: it requires both sender (plugin author) and receiver (one random pytest admin) to be available at the same time.

Being online is not easily achieved as there is no ultimate IM that everyone uses and we also have timezones.

I seen migrations being delayed for months, sometimes even more than an year due to broken communication channels so I am considering proposing few changes that should make it easier.

• Plugin author should open ticket on https://github.com/pytest-dev/meta/issues for adoption, this will be used as tracker, likely linked on a similar issue in the source repository.
• pytest-dev cores confirm that the plugin is meeting the documented requirements
• plugin author is invited to pytedev team, once he accepts github invitation he can create new repositories under pytest-dev. This also enables him to perform the transfer at any time he wishes.
• Once the transfer happens, one pytest-dev admin restores the rights of the plugin author. This is needed because transfer resets ACL and github secrets
• Now plugin author can fix secrets and perform other administrative changes related to the transfer, like reconfigure CI/CD pipelines.

This process does not require pytest admin and plugin author to work in tandem to perform the move and avoids double move of repository, which was quite an awkward move. If the light strikes the pytest admin mid process, we can end-up loosing control over the repository.

The only downside of this process is that the plugin author temporary looses administrative rights on the repository. Write rights are not affected at any moment because when author is added to the team, he also receives write rights to all repos.

Adoption of testinfra plugin to pytest-dev organization

I would like to propose migration of testinfra plugin under pytest-dev. This was already proposed to the author and he was willing to transfer.

Still there is one minor issue, as the project is quite old and established, he does not want to rename the repository to match the pytest- prefix rule we have plugins.

I do personally think that we can make one exception, on the ground of being a historical name (more than 4 years in production). IMHO, keeping most popular pytest plugins in a single place helps not only with maintenance but also with with making pytest better known and trustable.

This was proposed about an year ago at pytest-dev/pytest-testinfra#484 but I think we never got an answer from pytest-dev team.

Adopt pytest-order into pytest-dev

That is a tracking issue around for https://github.com/mrbean-bremen/pytest-order/issues/4

@pytest-dev/core please comment on this.

move pytest-dev contributing docs to pytest-dev/meta

I think this part of the documentation makes sense in pytest-dev/meta:

https://github.com/pytest-dev/pytest/blob/bc0020ad96f1d4b831655cdaa6b535f86ee15367/CONTRIBUTING.rst#submitting-plugins-to-pytest-dev

Shared pytest-dev PyPI account/token?

To push releases, @nicoddemus added a PyPI token with 1d3f27cef076df028ef6434b2d3bd29358c421c3 (which is stored in the PYPI_TOKEN secret in this repo).

Is this your personal account, @nicoddemus? Wouldn't it make sense to create a pytest-dev PyPI user, and then have a token which we can configure as organisation-scoped token for the pytest-dev GitHub organisation? That way, all pytest-dev plugins could add the pytest-dev user to PyPI (which would then be the recommendation instead of "We recommend that each plugin has at least three people who have the right to release to PyPI.").

This way, it'd also be easier for repositories to set up automated deployment via GitHub Actions (which could be another recommendation with an example), as they can use the existing organization-wide token and pytest-dev account instead of using their personal account.

Thoughts?

Adoption of pytest-sugar plugin to pytest-dev organization

This used to track Teemu/pytest-sugar#184 which is mainly about transfer of pytest-sugar plugin under pytest-dev org.

I think that the plugin already matches the documented requirements so it should be easy.

@RonnyPfannschmidt told me he could help with the move later in the week so it would be a good idea to add him to the source repo.

Adoption of pytest-github-actions-annotate-failures plugin to pytest-dev organization

pytest-github-actions-annotate-failures is a pytest plugin to annotate failed tests with a workflow command for GitHub Actions.

I want to submit the repository to pytest-dev organization because @ssbarnea suggested (pytest-dev/pytest-github-actions-annotate-failures#33) and I also want to make the future of this plugin safer.

Document and implement a smoketest hooking system for plugins

In order to be able to perform smoke-testing of pytest and its plugins we need to be able to allow plugins to embed and expose a minimal but representative set of smoke tests.

Basically we should be able to validate that pytest is not getting broken by a conflict between two plugins or a plugin and core. We should able to install as many plugins we want and still run a "pytest --smoke-test" kind of command that verifies that main functionality of pytest and installed plugins is still ok.

It is key to embed these tests within the plugins because that is the only way to test compatibility of both already released versions and unreleased ones (master branch).

Once we have a POC on how smoke-testing works we can create a CI/CD test that tests both scenarios: current repository with latest released version of siblings and also current repository with latest master versions of siblings.

This means that we considerably reduce the chance for core or plugin changes to break in production, as none will be able to make a release that does not pass the smoke-testing.

migrate to main branch from master for pytest and other repos

cc @pytest-dev/core

i plan to start this today with pytest + fixing affected pipelines
and would like to invite the rest of the repos to follow suit based on the maintainers preferences/