Docker Image Checks Rework

[CMNatic]

Hello!

I have modified the docker.yml GitHub action that is used to build and publish the Dockerfile to DockerHub. For quite a while, the check would fail on PRs and releases. This is likely due to the action changing/DockerHub API changing since we implemented the workflow on our end.

I have now used a different action and configured the docker.yml workflow to:

1. Run when a new release is made; this will tag it as rustscan/rustscan:1.11.11 on DockerHub, for example

2. It now successfully runs when a PR is made. However, the Dockerfile is only built, and isn't actually published. Otherwise, this means our DockerHub will be full of tags such as rustscan/rustscan:pr-400, but building it is important for CI/CD purposes, and the check will fail if it fails to compile RustScan.

3. It will now run when a merge or commit is made to the master branch, this will result in a latest tag being published to DockerHub, so people can try out new features/updates without having to wait for an official release.

4. Use a DockerHub access token (repo secret) to login to DockerHub instead of DockerHub Account Password

I've tested it on my end with a demo repository and new DockerHub repo: cmnatic/githubtest, but we will need to see how it works out for rustscan/rustscan :)

TODO: figure out how we can determine "what is stable" to create a "stable" tag for #533. Maybe this is just a re-tag of the latest release.

[CMNatic]

Ahhh so it is still having the same error because it's from a fork. https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow.

@bee-san I don't think we'll be able to fix this. We could just remove the Dockerfile check/build on PRs (remove):

    branches:
      - master

So that the check never happens here. I mean, we already have other checks that check if RustScan can be compiled so.... in hindsight, it seems a bit redundant that we're re-checking if it can compile via Dockerfile, we will just need to review any PRs that change the Dockerfile specifically. If RustScan can't compile via the Dockerfile, other checks such as Build/Test Suite will pick this up.

[bee-san]

Ahhh so it is still having the same error because it's from a fork. https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow.

@bee-san I don't think we'll be able to fix this. We could just remove the Dockerfile check/build on PRs (remove):

    branches:
      - master

So that the check never happens here. I mean, we already have other checks that check if RustScan can be compiled so.... in hindsight, it seems a bit redundant that we're re-checking if it can compile via Dockerfile, we will just need to review any PRs that change the Dockerfile specifically. If RustScan can't compile via the Dockerfile, other checks such as Build/Test Suite will pick this up.

Let's remove the check on PRs :)

[gaby]

@CMNatic The only way to test PR changes is to have a script or something that you run locally to pull the PR branch and build the image.

While you can publish images from a PR, it really only works for maintainers/contributors of a project, any fork opens a can of worms in terms of permissions/tokens.

In the meantime you could add support for posting the image to ghcr.io (GitHub Container Registry). Feel free to copy my CI from here: https://github.com/serge-chat/serge/blob/main/.github/workflows/docker.yml

Some notes:

• latest tag only gets updated if a new Tag/Release is created.
• main tag gets updated everytime something is merged into main
• each release triggers semver tags, ex you tagged v1.0.0 this will create:
  • v1.0.0
  • v1.0
  • v1
• By default tags dont have the prefix v you will need to add it in the patterns section of the yaml.
• this will build the image on each PR, but not publish it.