feat: publish docker images across different scenarios

[darrenvechain]

Description

This changes how we publish docker images:

1. On commit to main:

   • Publish master-latest to GitHub Packages
   • Publish master-${date}-${short sha} to GitHub Packages

2. On pre-release:

   • Publish vX.Y.Z-rc to GitHub Packages
   • Publish vX.Y.Z-rc to Docker Hub

3. On release:

   • Publish vX.Y.Z to GitHub Packages
   • Publish vX.Y.Z to Docker Hub
   • Publish latest to GitHub Packages
   • Publish latest to Docker Hub

FYI For pre-releases, it's important to append the -rc and set it as a pre-release:

Type of change

• [x] New feature (non-breaking change which adds functionality)

How Has This Been Tested?

Please refer to the last 4 workflows here: https://github.com/darrenvechain/docker-publish-testing/actions

Checklist:

• [x] My code follows the style guidelines of this project
• [x] I have performed a self-review of my code
• [x] I have commented my code, particularly in hard-to-understand areas
• [x] I have made corresponding changes to the documentation
• [x] My changes generate no new warnings
• [x] I have added tests that prove my fix is effective or that my feature works
• [x] New and existing unit tests pass locally with my changes
• [x] New and existing E2E tests pass locally with my changes
• [x] Any dependent changes have been merged and published in downstream modules
• [x] I have not added any vulnerable dependencies to my code

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 57.26%. Comparing base (e42227b) to head (4daeda1).

Additional details and impacted files

```diff @@ Coverage Diff @@ ## master #680 +/- ## ========================================== - Coverage 57.27% 57.26% -0.02% ========================================== Files 156 156 Lines 17218 17218 ========================================== - Hits 9862 9860 -2 - Misses 6392 6394 +2 Partials 964 964 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[libotony]

Do we do RC release on GitHub release? Usually, we would RC releases to production if it was tested ok. If we do RC release on GithHub, do we need to write release notes for both RC and production releases?

[darrenvechain]

Do we do RC release on GitHub release? Usually, we would RC releases to production if it was tested ok. If we do RC release on GithHub, do we need to write release notes for both RC and production releases?

@libotony you can chose the previous target when generating release notes, is this what you mean? See screenshot:

BTW, the -rc is not mandatory, you can use any suffix you like and it will publish with that suffix, I guess the description just has the example

You can also see an example of releases here: https://github.com/darrenvechain/docker-publish-testing/releases

[darrenvechain]

Hey @libotony I added the linter to the master file. Another option (if we want) could be to always run the linter and tests before docker publish, like in this commit. WDYT? https://github.com/vechain/thor/commit/0e645b93d7a0fd42dac6313d6e304c59b4659ddc

I guess the good part is that tests and linters always run before docker publish. Bad part is that actions become nested and slightly harder to follow, eg see this PR: https://github.com/darrenvechain/thor/pull/26 - unit tests fall under Docker Publish which doesn't make much sense:

[libotony]

Hey @libotony I added the linter to the master file. Another option (if we want) could be to always run the linter and tests before docker publish, like in this commit. WDYT? 0e645b9

I think it's not necessary to run unit tests before docker publishes. I propose running linter on master is I remember that the linter action has a feature that only linting changed codes on PRs, so a full lint on master might be necessary.