[CI] Docker image updates

[s3krit]

This PR makes a number of changes:

1. Do not push the parity/polkadot:latest docker image on new tag pushes
2. Introduce a new Github Action that will push to parity/polkadot:latest when a new release is published, that will build the image based on our deb package repo (this is done with scripts/docker/Dockerfile.release
3. Update the documentation in doc/docker.md to specify using our official docker images, rather than ones based on phusion. As per our Docker images maintenance policy: Use only official (in the _ namespace) third-party DockerHub images are allowed, both in direct use and inherited with FROM.
4. Update docker/Dockerfile to be based on paritytech/ci-linux:production as per the aforementioned Docker images maintenance policy.

[kirushik]

You can actually cache layers in docker builds with Buildx, which gives a significant performance boost here.

First you'd need to set up caching, with a separate step (prior build-push-action):

      - name: Cache Docker layers
        uses: actions/cache@v2
        with:
          path: /tmp/.buildx-cache
          key: ${{ runner.os }}-buildx-${{ github.sha }}
          restore-keys: |
            ${{ runner.os }}-buildx-

And then in your build-push-action itself you just add

          cache-from: type=local,src=/tmp/.buildx-cache
          cache-to: type=local,dest=/tmp/.buildx-cache

properties, and everything seems to work. (At least on that silly side-project of mine.)

[TriplEight]

it's better to use "Dockerfile" as an extension: release.Dockerfile. Other way many linters do not recognize it.

[TriplEight]

Suggested change

	io.parity.image.source="https://github.com/paritytech/polkadot/blob/${VCS_REF}/scripts/docker/Dockerfile" \
	io.parity.image.source="https://github.com/paritytech/polkadot/blob/${VCS_REF}/scripts/docker/release.Dockerfile" \

[TriplEight]

could use the same Label as in release.Dockerfile below

[s3krit]

The intention of this Dockerfile is to be used by users - i.e., for dev purposes etc., so it doesn't make sense to have vendor info and references to variables (like $VCS_REF) that won't be present

[TriplEight]

OCI recommends filling labels as a best practice. At least it can be handy to know where is the code of this Dockerfile, this could be in label.

[TriplEight]

also I have some questions on diff scripts/docker/Dockerfile scripts/docker/Dockerfile.release

• why different base?
• why different endpoint for the binary?
• why did you omit creating a user?

[s3krit]

why different base?

As per our README.md, I only claim our packages support the latest release versions of debian + ubuntu. It won't work with debian stretch - this is actually because the image used to build our release bins is base-ci-linux, which is based on buster also.

why different endpoint for the binary?

This dockerfile installs polkadot from our apt repository, so it gets placed in /usr/bin/ rather than /usr/local/bin.

why did you omit creating a user?

The polkadot user is created as part of installing the debian package.

[TriplEight]

which is based on buster also

oh, then we should change the base for the other image.

[TriplEight]

The polkadot user is created as part of installing the debian package.

It's worth mentioning in the comment there.

[TriplEight]

indentation here and below

[gabreal]

overall looks very good to me. what are the arguments to build and release docker images from github actions rather than gitlab ci (it's actually already there, could also use the deb package, runs on self-run infra)?

[s3krit]

overall looks very good to me. what are the arguments to build and release docker images from github actions rather than gitlab ci (it's actually already there, could also use the deb package, runs on self-run infra)?

The main advantage is that we trigger it when the release is published rather than tagged. Since we perform a bunch of tests after the tag is pushed but before the release is published, it makes more sense to only push our docker images once the release is actually published.

[TriplEight]

Looks good, thanks for updating both Dockerfiles to a new base.