chore: improve docker release pipeline

[Ferror]

A couple of improvements related to the docker release pipeline.

1. Building multiple architectures -> standard arm and amd
2. Using official docker GitHub actions
3. Specify Dockerfile argument to have control over asyncapi release expected version in the image

[github-actions]

Welcome to AsyncAPI. Thanks a lot for creating your first pull request. Please check out our contributors guide useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[derberg]

can you share what would you use ASYNCAPI_CLI_VERSION for? what is the use case for? cause for sure not development as we anyway take sources from npm

[derberg]

ok, now I see where 0.50 got from in the generator PR 😄

anyway, why not latest?

[Ferror]

Copy pastes be like that. So let me copy the same answer 😆

It's possible that the latest version will cache and you will end up with a docker image with an invalid generator version. With an argument, you can test past versions locally and ensure that you install the right generator version. Seems like a declarative approach.

Now that I think about it we should after the build actually "test" if the installed version inside the image is the same as release

[derberg]

@Ferror hey, we will need the same timeout as I mentioned in the generator PR. Can you add it. Afaik workflows now support it natively

[Ferror]

@Ferror hey, we will need the same timeout as I mentioned in the generator PR. Can you add it. Afaik workflows now support it natively

Can you elaborate on what it supports natively? I was more convinced to go with https://docs.github.com/en/actions/using-workflows/reusing-workflows

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[Ferror]

@derberg I think I put it all together, but to be honest I find the pipelines weirdly complex. And to have it cohesive must be a different pair of boots 😢

asyncapi/.github#256

[derberg]

@Ferror sorry, I probably did not explain myself correct, and used phrase timeout instead of delay. Sorry about that.

so basically, docker releases run on release event. Thing is that GitHub release might be created, but npm not yet published. The release pipelines were created over 3y ago, when GitHub Actions did not have all the features in place and we were also learning it live. As far as I remember, when I was setting that up, we made sure the semantic-release plugins are ordered properly https://github.com/asyncapi/generator/blob/master/.releaserc#L16 so the GitHub release is created last. Also logs confirm"

[11:25:20 AM] [semantic-release] › ✔  Completed step "publish" of plugin "@semantic-release/npm"
[11:25:20 AM] [semantic-release] › ℹ  Start step "publish" of plugin "@semantic-release/github"

but when I worked on the pipeline, we had random fails of docker publishing, and the conclusion was, after some investigation, that the fact that "logs say" package is published on npm, sometimes there is a "some-seconds" delay before it is available for download.

this is why we had this https://github.com/asyncapi/generator/blob/master/.github/workflows/release-docker.yml#L26 in pipeline for generator docker release.

now, after 3y and github acquisition of npm maybe that improved, and also why CLI docker release did not fail yet. But why taking a risk, we can just have a well described step that just does

name: Short docker release delay
run: sleep 1m #docker image installs generator from npm, this sleep protects this step from any delays on npm side

sorry again for lame initial explanation

[derberg]

@Ferror yo, do you plan to continue with this one? would be great

[Ferror]

@Ferror yo, do you plan to continue with this one? would be great

Yea. I forgot about it. I will add some improvements like we did for generator and we can release it :)

[derberg]

@Ferror sorry but can you make the bot happy? https://sonarcloud.io/project/issues?resolved=false&types=CODE_SMELL&pullRequest=675&id=asyncapi_cli&open=AYuBP0gk3G4WvsAlhREI&tab=why

[sonarcloud]

Quality Gate passed

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[derberg]

@Ferror 1s sleep is not enough. It was 1m originally. We can try 30s now (just changed) and in case it actually still should be 1m we can always modify pipeline. But going with 1s should be avoided

[derberg]

/rtm

[asyncapi-bot]

🎉 This PR is included in version 1.2.24 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀