Add a new workflow for building the mobile/library/python whl and uploading to pypi

[citrus7]

Create a new workflow that runs on manual dispatch that builds and repairs the mobile/library/python whl and uploads to pypi

Some things that still need work:

The workflow currently only runs on manual dispatch. We could change it to run when changes are made to the //library/python:envoy_mobile_wheel target, but the upload to pypi will fail unless the version is bumped in the BUILD configuration

The workflow is currently still configured for test PyPi. We need to set up an account and credentials for an official PyPi repo and add them to the repository as a secret

[repokitteh-read-only]

Hi @citrus7, welcome and thank you for your contribution.

We will try to review your Pull Request as quickly as possible.

In the meantime, please take a look at the contribution guidelines if you have not done so already.

🐱

Caused by: #44193 was opened by citrus7.

see: more, trace.

[citrus7]

I've updated this to push to non-test PyPi

[adisuissa]

/assign @phlax @abeyad

[phlax]

you need to fix DCO

also - please put this in the existing mobile-release wf - you will need to add an input to select which job to run and conditions on the jobs to enforce that

[citrus7]

Thanks for all of the reviews. I've tested the current iteration of the workflow on my personal fork and everything is functional with minimal changes: https://github.com/citrus7/envoy/actions/runs/24145104906/workflow

The workflow seems to broken in its current state: https://github.com/envoyproxy/envoy/actions/workflows/mobile-release.yml
On my own fork I've removed the broken android build sections, disabled caching and remote-rbe, and the push is to test-pypi (still using oidc) rather than production. Otherwise everything should be identical

[phlax]

thanks for iterating - almost there

[citrus7]

It seems that the mobile/release workflow has been broken for some time due to issue #37218

I took a look at the caching changes and tried to update _load_env.yml to mirror some similar workflows, such as _request.yml in this PR: #44339.

@phlax does this look correct to you? I've been able to run this workflow without errors on my fork after these changes, but I'm not sure if the caching itself is functional or doing anything.

[phlax]

not totally sure wrt caching and using the default reusable wfs - (ie _mobile_container_ci.yml or _run.yml) - for the reason that they are triggered after a request run and expect to get variables from that

this was one of the reasons that the other wf never got fixed

essentially the benefits are caching and rbe - not sure in this case if that is that important

its possible you could just run this directly with a runs-on rather than using the reuable wfs

[citrus7]

I've disabled caching and have modified _load_env.yml the minimal amount to make mobile_release.yml functional with no "invalid workflow" errors.

[phlax]

last nit then im gtm - thanks @citrus7