Continuous integration ====================== Create a ``.github/workflows/docker.yml`` file. As a base, use: .. literalinclude:: samples/docker.yml :language: yaml .. tip:: In most cases, you can reuse either the `docker-single `__ or `docker-django `__ workflow. For example: .. code-block:: yaml jobs: docker: uses: open-contracting/.github/.github/workflows/docker-single.yml@main .. note:: This assumes there is already a :doc:`"CI" workflow <../python/ci>` that runs tests on the ``main`` branch. .. note:: The `docker/build-push-action `__ step uses `BuildKit `__ by default. If you need to build multiple images, then for each image: #. Include a ``docker/build-push-action`` step. #. Set either: - The path to the Dockerfile with the `file `__ key - The path to the directory (`context `__) with the ``context`` key #. Add a suffix to the repository name under the ``tags`` key. .. The following would simplify the workflow somewhat. However, it would not work when building multiple images, producing an inconsistent approach across repositories. # https://github.com/docker/metadata-action#usage - uses: docker/metadata-action@v3 with: images: ghcr.io/${{ github.repository }} tags: | type=ref,event=tag # https://github.com/docker/build-push-action#usage - uses: docker/build-push-action@v2 with: push: true tags: ${{ steps.meta.outputs.tags }} labels: ${{ steps.meta.outputs.labels }} Note: The docker/metadata-action step with ``type=ref,event=tag`` automatically generates the `latest `__ tag. Reference: - `Publishing a package using an action `__ - `Troubleshooting `__ ``docker/build-push-action`` step