git tag was not created for 4.3.0

[MartinThoma]

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

[MasterOdin]

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.

[stefan6419846]

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.

[MartinThoma]

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.

[kitterma]

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.

[stefan6419846]

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?

[kitterma]

We do.

Scott K

[MartinThoma]

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)

[kitterma]

In Debian our tooling is set up to pull from a signed tag, so for us, that's what's most important.

[MartinThoma]

@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.

[MartinThoma]

@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

[kitterma]

Yes. I can wait for the next release.

Scott K

[stefan6419846]

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/

[MartinThoma]

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:

[kitterma]

That worked. Thanks.

[pubpub-zz]

@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

[pubpub-zz]

@MartinThoma +1 ?