revive pytest-html maintenance

[ssbarnea]

pytest-html needs an active pool of maintainers as it slowly degraded.

I am offering to help with most maintenance tasks and especially around making/keeping CI/CD green and reviewing upcoming contributions.

pytest-html is a key ingredient in testing implementation we use on several openstack projects, also directly used with my pytest-molecule plugin, so I have a strong interest in keep in it working.

I hope others will also be interested to join this, as it much better to avoid me becoming another single point of failure.

One of the first things I want to do is to migrate testing to Github Actions as it far more reliable and flexible than Travis, and assure we have a devel job with tests with unreleased versions of major dependencies, like pytest (so we avoid surprises when they release). like we had with pytest-6.0.0. Also Github Actions can take care of release process in a safe way, which involve using a bot account to publish releases.

PS. I do not yet have the rights on the project.

[ssbarnea]

@pytest-html-admin please assist.

[webknjaz]

@pytest-dev/pytest-html-admin @pytest-dev/pytest-html-developers ^

[ssbarnea]

Indeed, as non member I cannot mention these teams and when I hover over the links I get "Hovercard not available", clicking gives a 404, which is usually what a private team would do (common but confusing security measure)

[davehunt]

I don't agree that pytest-html maintenance needs 'reviving' or that it's slowly degraded. I'm certainly not an active maintainer these days, but @BeyondEvil has been doing a great job of keeping the plugin going, and without him I'm certain the plugin would be in a far worse state. That said, there's always room for improvement, and it sounds like you have some good ideas. I encourage you to work with @BeyondEvil to get these implemented, and I welcome you to the project.

[ssbarnea]

Yes @BeyondEvil did a great job and without him the project would be in a very poor state. Still this does not mean that the project does not need more attention, #315 got stalled/blocked because lack of a simple rebase.

https://github.com/pytest-dev/pytest-html/pull/320/files adds testing with devel. There is also a LOT of work to be done on maintenance, for example this project is not tested at all with pytho3.8, which is the current stable version of python. Scheduling daily or weekly runs on master can be easily activated by anyone using travis interface.

[RibeiroAna]

Hi there, unfortunately since last year I could not find time to contribute to Pytest-HTML since I have a full time job and this year was not particularly easy for me (I broke my leg at begging of the year, before all the pandemic thing). I still have a lot of interest in the Pytest project and I hope to return to the project whenever it's possible. By now I don't know what I can do to contribute since I have been away of the project for so long.

[nicoddemus]

Hi everyone!

Indeed, as non member I cannot mention these teams and when I hover over the links I get "Hovercard not available", clicking gives a 404, which is usually what a private team would do (common but confusing security measure)

TBH I was not aware of that, I thought those teams were public and everyone could mention them.

I particular have seen @ssbarnea's work in general and would welcome him as a contributor to pytest-html. If nobody objects I would be happy to send him an invitation (although his "Collaborator" badge on the top of his comment frames already say he has been invited to contribute to the project, so perhaps @davehunt already did it?)

Still this does not mean that the project does not need more attention, #315 got stalled/blocked because lack of a simple rebase.

Indeed that's unfortunate... having more contributors with write access certainly helps mitigating this.

As for myself I try to help here whenever I can, but my time is already spread thin over pytest itself and other plugins where I'm the sole maintainer, so I would be more than happy to have more people joining pytest-html. 👍

[nicoddemus]

I broke my leg at begging of the year

Ouch! Sorry to hear that @RibeiroAna. Espero que nessa altura tu já esteja melhor!

[gnikonorov]

I don’t mind taking on an active role in maintaining this plugin if no one objects. I’ve been meaning to contribute to it for a while.

[nicoddemus]

@gnikonorov you have my vote, you have already proven a valuable member to the pytest core team, I'm sure you can greatly help out pytest-html as well. 👍

[BeyondEvil]

I particular have seen @ssbarnea's work in general and would welcome him as a contributor to pytest-html. If nobody objects I would be happy to send him an invitation (although his "Collaborator" badge on the top of his comment frames already say he has been invited to contribute to the project, so perhaps @davehunt already did it?)

Hi @nicoddemus

That was me (attempting) to add @ssbarnea as a "full" contributor. Obviously I failed.

I attempted to do it the correct way just now (or at least what I perceive to be the correct way, it doesn't seem to be documented anywhere), but it looks like I don't have the correct permissions?

I'm helping @davehunt to maintain:

pytest-html
pytest-selenium
pytest-variables
pytest-base-url
pytest-metadata

I'm in the admin and developers teams for all of the above plugins, but it seems I don't have the correct permissions to add others to those groups.

It's up to yourself and Dave to decide if and what access I should have to those teams, but being an admin of a plugin should at least give me the ability to add contributors to the -developers teams imo.

I'm also more than happy to add @gnikonorov as a contributor to the plugin and team.

[BeyondEvil]

Hi there, unfortunately since last year I could not find time to contribute to Pytest-HTML since I have a full time job and this year was not particularly easy for me (I broke my leg at begging of the year, before all the pandemic thing). I still have a lot of interest in the Pytest project and I hope to return to the project whenever it's possible. By now I don't know what I can do to contribute since I have been away of the project for so long.

Sorry to hear that! I hope you're feeling better now! @RibeiroAna

One way to contribute in a big way, is to be available to look at PRs. Even tho you've been away, I don't think the plugin has changed in any significant way. And, seeing how you've been a long time contributor, your input will be greatly appreciated! 🙏

One thing that has frustrated me, which is true for all the plugins I help maintain, is the slow turnaround/feedback-loop. I'll create a PR (maintenance, bug fix, new feature, whatever) and it can be days (sometimes even weeks) before I get any feedback or an approval. This means that if a change is requested or a discussion needs to happen - it can take a long time before the PR is finally merged.

This leads to a couple of issues:

• We risk loosing community support because they might think that the project has been abandoned. Something that @ssbarnea mentioned in an email to the pytest-dev mailinglist.
• Turnaround/feedback-loop delay escalates even further due to contex-switching in the sense that if too much time passes between feedback etc. it takes longer to re-understand what it is you're dealing with, and you risk pushing the work even further into the future.

I'm the first to admit that I'm guilty of all of the above and I understand we live busy lives, I do too!

But a problem not raised, is a problem not fixed.

[BeyondEvil]

One of the first things I want to do is to migrate testing to Github Actions as it far more reliable and flexible than Travis, and assure we have a devel job with tests with unreleased versions of major dependencies, like pytest (so we avoid surprises when they release). like we had with pytest-6.0.0. Also Github Actions can take care of release process in a safe way, which involve using a bot account to publish releases.

I think more or less all pytest-dev plugins (incl. pytest itself) uses Travis, so I'm against moving to Github Actions unless there's very good reason to do so.

I haven't experienced any reliability issues with Travis, and I do believe they support scheduled runs - I'm just not sure if they are available on the free/OS tier. That is something I'm going to look into right now.

I do however agree that we need "devel" testing!

As far as release process goes, apart from some manual steps (basically changelog stuff), I don't see any issues with the current process. But I'm happy to hear detailed feedback on how Github Actions would improve that process.

[ssbarnea]

I am really happy to see everyone stepping in to help here. It make me quite positive about the future as we identified few things to improve. Yes, very often the admins or even cores forget the user experience interacting with a repo can be quite limiting, it happened to me several times and I ended up creating and using a spare github account for validating different scenarios.

The good part is that some time ago GitHub made the process easier with a set of default access rights. "Read" is useless for opensource as anyone already has it but the rest are important to know.

Triage can be given without much worry, i allows user to perform secretary work: open/edit/close issues, open/edit/close PRs but NOT voting review or merges. Usually I send the invite to Triage right away when someone takes interest in project (after checking a little his social history), sometimes I do even without being asked.

Write is mainly a core, so he perform voting reviews and can push. If the repository is well configured to require green CI and one review, giving this right is also easy, as they would be very unlikely to do mistakes alone (they would not be able to merge their own PRs).

Admin gives full rights and is usually needed for some plumbing work like enabling/disabling different CI/CD integrations, editing repository topics or managing the branch access. I find myself editing these quite often of some repositories that I nurture on ansible-community but in general is not needed. An Admin needs to know very well how github ACL works and be a trustable person, not someone that would ever go rogue.