Release using github actions

[lassemand]

No description provided.

[limemloh]

So far we have tagged backend releases using backend/*.
But I see the consistency in tags being named the same as the tag on the image.

[limemloh]

I would prefer not to have this sort of abstraction, since it is moving logic somewhere else, and it now adds requirements on how secrets are named.
Sometimes copying and pasting is just easier to maintain, since we now have to update another repo and ensure we don't break stuff elsewhere and the logic in .github become more and more complex as we try to fit it to everything. It already contains logic for cargo which is not relevant for this project, making it harder to maintain.

[lassemand]

We do not have to fix the entire organisations release flow using this generalisation.

We have certain release flow, they seem much alike, lets ensure consistency. I do want us to come into a repository and know how we release in this repository. We have not been consistent in the past.

Furthermore such generalisation would ease the use of shared components in the future such as smoke test etc.

[lassemand]

If you want the content which differ:
prefix or not, version format (semantic or build version extended), version validation (file based validation or not), service name conventions (what should be the name of the service in dockerhub)

And yes fixing secrets namings helps us. The next thing I am going to do is to automate this secrets generation from within terraform. Then it helps that we have fixed docker secrets so I do not have to guess on the name. https://github.com/Concordium/concordium-infra-terraform/blob/main/iam/ghactions.tf

We can extend the repository with the docker repositories that we need access to from within a git repository.

[limemloh]

I would much rather have the release flow in this repo rather than code golfing.
Consistency is not generalizing things, and this is introducing a new approach yet again, which makes this inconsistent with what we already have.

[lassemand]

Based on the talk we had we came to the conclusion that the already migrated jobs would be reusable workflows and the new ones would be copy pasting.

That means that this should be fine for now.