[Task]: Migrate docker image push to github action

[KevinMind]

Description

Currently we still use circleCI to build and publish our docker image. We have an action to build and publish the image from github actions but currently our deployment pipeline is listening for circleCI events to trigger deployments.

We will need to modify our deployment pipeline to listen for appropriate github events or manually trigger deployment from addons-server actions. There are pros and cons to both approaches and we should discuss them and decide on a strategy.

We could also consider in the scope of this task, or another task to push directly to GCP registry.

Plan

We have a CI workflow in addons-server that is currently triggered by:

• release:publish - maps to a tag release to staging
• push:branch.main - maps to a latest release to dev

We have enabled the workflow_run event to be sent to event-router

With these events we can trigger dev/staging deployments using the image pushed via github actions. The next steps are defined in the AC below.

Acceptance Criteria

Acceptance Criteria

Beta Give feedback

1. remove release.yml workflow #14865
   +0
   
2. create a PR/branch for the modified deployment workflows #14866
   +0
   
3. create events in event-router.yml that targets the above branch for running deployments #14867
   +0
   
4. Refine the deployment workflows until they are consistently working #14868
   +0

Checks

• If the issue is ready to work on, I have removed the "needs:info" label.

┆Issue is synchronized with this Jira Task

[KevinMind]

Learnings.

1. We cannot rely directly on the "release" event, because a release can be published and there is zero verification that the tag being released is valid, tested and at the time of this event, there is not even an image to rely on.
2. We could rely on the workflow_run event and listen for the CI workflow. This workflow already builds and pushes the image as well as testing. We would need to filter the event for the ref triggering, either a tag or master and deploy accordingly.
3. We could rely on the workflow_job if we wanted to have a more granular dependency. This would allow some jobs in the CI workflow to fail, but it would require us to target a specific job and determing how to do that is difficult.