search

Nitrokey / nitrokey-app2

Graphical application to manage and use Nitrokey 3 devices
https://www.nitrokey.com/products/nitrokeys
Apache License 2.0
87 stars 14 forks source link

PyPI not up-to-date #289

Closed brevilo closed 1 week ago

brevilo commented 1 month ago

Please add PyPI to your release process. It still lacks the 2.3.2 release.

Thank you

robin-nitrokey commented 1 month ago

Thanks for the report! The workflow for publishing on PyPI is still there but it did not get triggered for this release. I don’t see why. released: published should also be triggered when marking a pre-release as released. Maybe @daringer @mmerklinger you see the reason?

mmerklinger commented 1 month ago

I haven't confirmed it through testing, but I have an assumption. We usually create a release as a prerelease and then change it later to release. The workflow for PyPI is only triggered on the release event. Changing it later on probably doesn't trigger the other event.

The thought of not triggering prereleases to PyPI was to not have a testing release pushed to users. I see two options:

  1. See if we can trigger the workflow on such a change.
  2. Change our release process, which is mostly like that due to manual signing of the Windows artifacts. Though we also use it to make some final release tests sometimes.
robin-nitrokey commented 1 month ago

I also had that idea, but looking at the old workflow runs, it seems like the previous releases were first tagged as prereleases too. Also, the documentation refers to this site that says:

Action type: released A release was published, or a pre-release was changed to a release.

mmerklinger commented 1 month ago

You are right. I also checked when we last time changed the release event behavior and it was long time before the last published release on PyPI. I'm not sure right now what is going on, but I can conduct some tests in the coming days.

mmerklinger commented 1 month ago

Thinking about the release process I have a new assumption. We do the following:

  1. Create a new prerelease. This triggers all pipelines, except the PyPI.
  2. We edit the release by uploading the signed Windows artifacts and remove the prerelease.

The step two happens in one operation, which probably doesn't trigger the event release with type released, but event release with type edited. This would make sense to me, because in the beginning we didn't use the prerelease as a step for signing the Windows artifacts.

mmerklinger commented 1 month ago

So, regarding my assumption from the last comment I was right. Means, we just need to adapt our process in splitting step 2. Would come down to:

  1. Create the prerelease. Triggers pipelines with the event release and type prerelease.
  2. Edit the prerelease by uploading the signed artifact and removing the unsigned artifact. Triggers pipelines with event release and type edited.
  3. Edit the prerelease again and remove the prerelease option. Triggers pipelines with event release and type released.

I will keep the issue open for now to verify the process with the next release.

mmerklinger commented 1 week ago

The latest version 2.3.3 is available on PyPI again.