I don't think this solves the problem. The issue is that the python package might be unchanged if a PR only changes the compiled code and not the python code. Refusing to tag a release on github unless python code changes seems worse than having a missing Python package on occasion.

I suspect a proper fix would be to either allow different versions of the 2 packages, or to simply ensure the python package contains the version number for the main package - then the python package will always change when we have a new release and they'll always be in sync.

Also the changes to add workflow_dispatch into the CI are definitely wrong - see:

• Error: https://github.com/panda-re/panda/actions/runs/10218265576
• Fix: ed5c2f1

Hello Andrew!
Ah I see what you mean, I thought you just wanted to make sure that say for v1.8.31, you can get the identical package either through GitHub releases or PyPi. At least as shown on the Issue, I checked the hashes, it seems like this worked pretty well so far. So I just refactored so that PyPi release is the first step for releasing uploads. This would mean if for some reason PyPi upload failed like just now, there is no extra release and need to manually fix that, and we just have to fix the deployment (or re-run it with workflow dispatch?). This would align with "simply ensure the python package contains the version number for the main package - then the python package will always change when we have a new release and they'll always be in sync."

Although I do wonder if we should retroactively upload 1.8.27 and I think 1.8.31 on Pip too? I can ask Brendan if he can do this too, I'll be meeting him later today for LAVA upgrade work. Hopefully this PR should avoid any more manually retroactively fixes too.

As for the first option, we can have publish_docker.yaml only executed manually rather than automatically the moment there is a push to dev. So perhaps when manually running a workflow, you can say publish to PyPi only, or create new release with debian and PyPi? Although this versioning might be confusing, but I can try a first draft of this refactor for you if this is something to try?

And yes that was a typo originally on the publish docker, sorry about that!

https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/manually-running-a-workflow