Updating Deployment

[AndrewQuijano]

Hello,
This should be covering the last batch of chances to publishing GitHub action.

1. First, avoid publishing the same artifact twice, which caused an issue with the release that occurred last deployment

Already fixed here: #1522

2. Changing the workflow to fix Version disconnects between deb and python packages #1501 Essentially, having the first step be uploading to PyPi, this should enforce that the versions between releases and pip will be aligned permanently. If the PyPi upload fails, there will be no release created.

I should note, I believe you'd need to manually upload 1.8.28 and 1.8.35 to PyPi, not sure if you'd want to also delete 1.8.22.dev12 and 1.8.21.dev1 from PyPi, but this should hopefully make sure Pip is retroactively fixed to be in lock step after version 1.8.21

3. Swap order of containers being built, so we can leverage caching for faster publishing of pandadev and panda containers.

4. I also removed duplicate code in regard to updating documentation used on both dev and stable branches.

[AndrewFasano]

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

[AndrewQuijano]

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