Being able to fast-track (manually?) generating and deploying HTTP service on release

[Lothiraldan]

Right now, we are generating a Docker image with missing models for the HTTP service so we cannot deploy at the end of the release.

But that means that all code change, including hotfixes, will need to wait for the next data-pipeline to finish which is sub-obtimal.

[marco-c]

We could:

1. Release a new version (having a way to avoid triggering the hook automatically)
2. Retrigger the tasks to build and depoy the HTTP service, using the new released image

Possibly, if we had a way to release a new version without triggering the hook automatically, we'd avoid unnecessarily rerunning the whole pipeline.

For 2, we should check if it is feasible currently with Taskcluster.

[marco-c]

@La0 maybe you could work on a script to do what I said above: take the latest run of the HTTP build task (e.g. https://community-tc.services.mozilla.com/tasks/NINALdhXTkK553pDPGgl-g), edit it to use the latest released version of bugbug, run it in the same task group, then do the same for the HTTP push and HTTP service deploy tasks (e.g. https://community-tc.services.mozilla.com/tasks/W6lZgT5OS1uKqDF-0W1KWg and https://community-tc.services.mozilla.com/tasks/Rrc8S3BDTV-CMshq4D4ddg) after changing their dependencies to point to the new build task.

[La0]

Sure ! We'll have to discuss the workflow details, but i'll work on that next week.

[marco-c]

I'm still doing this manually for now, the process is mostly the same as before. The only difference is that when editing the HTTP build task, I don't only bump the version numbers, but I also add a --build-arg TAG=latest to the Docker build commands (so the build takes the latest trained models, instead of trying to take the trained models belonging to the latest released version, which obviously don't exist yet since it is a hotfix that didn't run the full training pipeline).