Add automation to track upstream releases

[mjnowen]

Please can automation be put in place so that releases are automatically tracked from:
https://github.com/editorconfig-checker/editorconfig-checker/releases

[klaernie]

@mmicu Am I correct in that you're currently the only maintainer on PyPI? Would you be open to adding me as well, so I can automate release uploading?

My general plan would be configuring renovate to update the versions according to the upstream releases, and adding a release-please action that generates a release-PR to review before releasing a new version. And then follow this up with a GitHub Action that is triggered by the tag generated when the release-PR is merged, which then runs the test suite one last time before uploading to PyPI.

[echoix]

Have you also considered using repository_dispatch/workflow_dispatch triggers on a workflow? That would allow you to launch a job in this repository, from another repository.

We can see this in some projects where the pre-commit is in another repo, and during the release of the parent project, the second repo is released right before the final publishing of the release of the parent, like ruff.
https://github.com/astral-sh/ruff-pre-commit/blob/25a8c8da6c24a3b9a1a536e2674683dd0eead5d6/.github/workflows/main.yml
https://github.com/astral-sh/ruff/blob/ab1011ce70913a2ba66b51b569baed3bcb434602/.github/workflows/notify-dependents.yml#L14-L29
https://github.com/astral-sh/ruff/blob/ab1011ce70913a2ba66b51b569baed3bcb434602/.github/workflows/release.yml#L275-L282

I also remember that this set of solution for doing chat ops and executing in another repo uses these dispatch events extensively https://github.com/peter-evans/slash-command-dispatch

[klaernie]

I did consider this pattern at work, but find it lacking, since it tightly couples both repos - if one of them leaves the set of shared admins a broken workflow will require efforts to fix. Also this requires issuing tokens that are allowed to run actions in different repos, making any attempt of hardening more complex.

So at least in my professional work I've decided against using this pattern, and have always relied on loosely coupling with replaceable dependency updaters like renovate - where one could just as easily substitute another tool or even a human if the need arises.

[echoix]

It's totally valid and reasonable, so yes, you can say you considered it and it isn't appropriate here. I understand the intention to have each be independent, instead of dependent and orchestrated by the parent repo

[mmicu]

@klaernie, yes, I am the only maintainer and I'd be happy to add you as well. The only concern that I have is that the PyPI artifact is directly connected with my personal PyPI account.

[echoix]

Is using trusted publishing (pypi's term for OpenID connect) a possibility for you? You could then use id-tokens from github actions.

https://packaging.python.org/en/latest/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/

https://docs.pypi.org/trusted-publishers/

[klaernie]

@mmicu If I understand it correctly the only thing connecting the editorconfig-checker package to you personally is the declared authorship and the permissions in PyPI. But I've also seen that PyPI has support for organizations, I'll take a look if that brings us benefits. Feel free to add me anytime, I'm klaernie, aka kandre@ak-online.be there as well.

Anyway I'd go the OIDC/trusted publishing direction, since it avoids storing any specific token for PyPI in GitHub Action secrets, and uses token issued by GitHub with a short expiration instead.