Build containers in CI/CD

[fabriziosestito]

Uses github actions to build containers on every merge on main.

If a release event is detected a container with the release tag is built and pushed, otherwise the container the rolling tag container gets updated.

It also supports cache + manual dispatch.

[dottorblaster]

[fabriziosestito]

This needed to add the capability to use an external cache

[dottorblaster]

Dude are you really commenting your own PR? 😂

[fabriziosestito]

aha yes i thought it would help reviewing since it is a magic yaml

[fabriziosestito]

Uses GitHub Action cache

[stefanotorresi]

Since #248 is causing a conflict on the workflow file name here, I also realized that this workflow doesn't actually depend on the build job of the CI workflow, so we might as well have it in a completely separate file, like the one for the OBS delivery.
What do you think?

[fabriziosestito]

Since #248 is causing a conflict on the workflow file name here, I also realized that this workflow doesn't actually depend on the build job of the CI workflow, so we might as well have it in a completely separate file, like the one for the OBS delivery.
What do you think?

@stefanotorresi we choose to depend on the build job since it performs the testing as well. it would be nice to have separate jobs for testing etc but I think it still means the job should be in the same workflow to be dependent to the test stage?

We could also create a composite action for test/vet check and execute it again in the docker workflow

[stefanotorresi]

Hmm, you make a good point, but the discussion then gets tricky: by the same logic, we shouldn't build broken code in OBS either.
Shall we consolidate all the builds in the same workflow where all the downstream jobs are blocked by the one where we execute the tests, then?

[fabriziosestito]

@stefanotorresi I think this is an option. if we want to keep separate workflows we will need to move the test steps in composite action, and repeat the step in every workflow that is needed, this way we repeat the step,yes, but the workflow will work in a parallel fashion.

EDIT: I'm leaning more toward the first option you proposed tho, it's easier to add a test step and let the other jobs depend on it, also they will work in parallel also this way.

[stefanotorresi]

EDIT: I'm leaning more toward the first option you proposed tho, it's easier to add a test step and let the other jobs depend on it, also they will work in parallel also this way.

All right then; unless the rest of the team has objections, go for it!
One workflow to rule them all.

[stefanotorresi]

Let's consolidate all the CI jobs into a single workflow, with all the CD jobs depending on the test one.

[rtorrero]

Let's consolidate all the CI jobs into a single workflow, with all the CD jobs depending on the test one.

I'm on it already

[stefanotorresi]

Good. As discussed in Slack, I'll leave a follow-up to fork https://github.com/arbulu89/continuous-delivery in the trento-project org.