Add credentials when pulling img in CI

[antgamdia]

Description of the change

This trivial PR just adds the docker registry credentials when pulling the images used in the CircleCI runners.

Benefits

Avoid rate limits, maybe?

Possible drawbacks

N/A

Applicable issues

• fixes Use docker creds in CI and cache images #2985

Additional information

After and before:

[netlify]

✅ Deploy Preview for kubeapps-dev canceled.

Name	Link
🔨 Latest commit	e67a3d4
🔍 Latest deploy log	https://app.netlify.com/sites/kubeapps-dev/deploys/62d03877a072b200083cb4cc

[castelblanque]

I would like to understand why this change is necessary.

Avoid rate limits, maybe?

Have we hit the rate limits of Docker registry due to using CI?

What happens with forked repos? Those won't have the DOCKER_* variables. Jobs like build_go_images would fail in those cases?

[antgamdia]

Have we hit the rate limits of Docker registry due to using CI?

I don't think so (yet), but Circle CI does recommend adding the credentials, see:

CircleCI has partnered with Docker to ensure that our users can continue to access Docker Hub without rate limits. As of November 1st 2020, with few exceptions, you should not be impacted by any rate limits when pulling images from Docker Hub through CircleCI. However, these rate limits may be implemented for CircleCI users in the future. This is why we are encouraging you and your team to add Docker Hub authentication to your CircleCI configuration and consider upgrading your Docker Hub plan, as appropriate, to prevent any impact from rate limits in the future.

So that's why I'm sending this PR. Otherwise, #2985 should have been closed when triaging.

What happens with forked repos? Those won't have the DOCKER_* variables. Jobs like build_go_images would fail in those cases?

I guess it will roll back to the un-authenticated behavior, that is, using the circleci default account.

[castelblanque]

I guess it will roll back to the un-authenticated behavior, that is, using the circleci default account.

Some months ago we had problems, as a PR introduced those variables, but it was making forked CI runs to fail as variables were missing in those forked repos. The CI definition yaml is cloned too into the forked repos, as any other file. CI execution is done accordingly, having as a context the forked repo, therefore it fails.
Could you please give it a try in a forked repo to see the behavior?

[antgamdia]

Could you please give it a try in a forked repo to see the behavior?

Yes, of course, a good idea to double-check our assumptions 😅 .

I've merged this branch into my branch's main and, as supposed it falls back to the unauth behavior:

Starting container cimg/go:1.18.4
cimg/go:1.18.4:
  using image cimg/go@sha256:0c9917d6b4d17b8dd5133d4a9baa0ed0e0d0117413ee2cea6f3dd7522637982b
  pull stats: Image was already available so the image was not pulled
  time to create container: 7ms
Warning: No authentication provided, using CircleCI credentials for pulls from Docker Hub.
  image is cached as cimg/go:1.18.4, but refreshing...
1.18.4: Pulling from cimg/go
Digest: sha256:0c9917d6b4d17b8dd5133d4a9baa0ed0e0d0117413ee2cea6f3dd7522637982b
Status: Image is up to date for cimg/go:1.18.4
Time to upload agent and config: 341.066953ms
Time to start containers: 375.925156ms

Source: https://app.circleci.com/pipelines/github/antgamdia/kubeapps/2518/workflows/50edcf30-7120-4f4e-b301-2be5baa2fdea/jobs/19829

[castelblanque]

it falls back to the unauth behavior

Great, thanks for checking!!