Open MartinThoma opened 1 month ago
I wonder if it's a limitation of using secrets.GITHUB_TOKEN
for trying to create a protected tag, where the user associated doesn't have admin/maintainer rights on the repo? Might need to use a PAT, though that feels like it would bypass the entire reason to have protected tags.
As far as I remember, we already had discussions about PATs, but tried to avoid it as they have a limited lifetime as well. According to the docs, our approach should work, although it seems like push protections prevent this from actually running correctly.
Yes, my guess was as well that this is a security mechanism. I'm uncertain if there is a reasonable way around it.
In the end, I also would trust you @stefan6419846 / @pubpub-zz enough to handle releases for pypdf. So I'm also thinking about simply giving you maintainer permissions.
It looks to me like there's a tag there (at least now), but it's not signed, which is a departure from previous releases.
Yes, the tag has been created in the meantime, but it should have been created automatically - this is what this issue seeks to further analyze. In this case, it seems like there is some setting which show an issue on the GitHub UI:
Do you rely on all tags being signed?
We do.
Scott K
I could force-push a signed tag. Could that cause issues?
The workflow will attempt to create a new release on pypi, but that will fail (which is ok)
In Debian our tooling is set up to pull from a signed tag, so for us, that's what's most important.
@pubpub-zz @stefan6419846 You have done a great job as core contributors to pypdf for an extended period of time. I trust your intentions and abilities, hence I gave both of you the "Maintainer" permissions on the pypdf repository. That should mean you can trigger the release by merging a "REL: XYZ" commit in future.
@kitterma pypdf releases relatively often. Is it fine when we just release the next release with a signed git tag? We could release 4.3.1 today :-)
edit: PR is prepared https://github.com/py-pdf/pypdf/pull/2764
Yes. I can wait for the next release.
Scott K
Release 4.3.1 failed in CI again.
As far as I understand, the executing user (probably GitHub Actions in this case) needs push permissions for protected branches - even if just creating a tag: https://github.blog/changelog/2021-11-19-allow-bypassing-required-pull-requests/
I've created the tag manually via git tag -s 4.3.1
, pasting the part of the changelog, git push --tags
.
I'll look more into that next week :eyes: :smiling_face_with_tear:
That worked. Thanks.
@MartinThoma Have you been able to progress in your analysis? Just for information we have some PRs in the pipe / already merged that should be released in 5.0.0 although we are not ready yet to tag it
@MartinThoma +1 ?
This is mostly a reminder for me to check why the git tag was not created for the commit
REL: 4.3.0
. Something does not work as expected with https://github.com/py-pdf/pypdf/blob/main/.github/workflows/release.yaml