Use Docker in GitHub Actions?

[JF002]

So, currently, the Github Actions script runs the builds in a "github" virtual machine based on Ubuntu.
As I have already said, I don't know Github Actions that much and barely use them, but they are really useful for other developers, testers and allow to check that the branches build before merging them (and will also allow to add more tests in the future).

My only complain about Github Actions is that they are described in this specific yml file and run into a VM from Github, which means that the build chain is specific to github and cannot be reproduced on developers dev stations or moved to another CI.

Also, this yml file is more or less a duplicate of the Docker container we've also added in the project. I really like this container as it allows anyone to build the whole project on their computer without needing to setup a complex dev environment.
When I first created this docker container, my plan was to use exactly the same container on dev computers and on the CI. Unfortunately, installing, managing and maintaining a CI build server takes time, and I prefer to spend my time working on InfiniTime instead of a CI infrastructure.

Now, I've recently discovered it should be possible to use the Docker container into the Github Actions workflow. I think it would be great to use this feature, so that we ensure that the builds we do on our computers and the ones built on Github are the same (same versions, sames options, same tools).
I think this would also allow to improve the build chain (with more features, tests,...) without having to do it twice (once in Docker, once in Github Actions).

Is anyone up to the task to move our Actions to Docker ?

[ntindle]

So the task is basically swap the current GH actions to pull down the existing container and run it?

(sorry if I’m misunderstanding. Just saw the new repo from the Pine October Update and read at the bottom of the Readme you need some CI help)

[JF002]

@ntindle Exactly! We already have the build docker container. It builds the entire firmware and all the variations (standalone firmware, firmware for MCUBoot, MCUBoot image file, DFU, recovery firmware). I personally use it exclusively to generate binaries for the releases.

The Github Action is nice and allows to easily build binaries without a dev environmnent on the computer, but it's currently not complete (only builds the dfu file) and it's basically the same as the build docker written into another form.

So the idea is to use the docker container into the Github action so that we avoid the code duplication and ensure it's working fine and it's maintained. If I understand the doc correctly, this should be possible, but someone has to do it ;)

[ntindle]

So steps are

• Build Docker image from source
• Run docker image using docs linked above
• Use the resulting output as a check in GitHub statuses to prevent merge on failure?

[JF002]

I'm not sure how it'll work for github, and we might need to slightly modify the current dockerfile so it still work on developers workstation and also work in github action.
If needed we can push the image on the DockerHub (I can create an account on behalf of the project).

Then, yes, the idea is to run the current github Action workflow using this container instead of the current one (build, check fails if build fails, provide binaries if the build succeeds).

[carlosperate]

I think the link provided is more about creating a "GitHub Action" using Docker, which are used for individual "job steps", and each step spins out a new container:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: This steps runs inside its container
        uses: <my_custom_docker_action>
        with:
          ....
      - name: This other step runs in a new container
        uses: <my_custom_docker_action>
        with:
          ....

Probably what want is to run a full job inside a container like this:

jobs:
  build:
    container: <my_custom_container>
    steps:
      - name: All these steps run inside the container
        run: ...
      - name: All these steps run inside the container
        run: ...

Looks like there is a docker image in DockerHub based on the docs?

• https://github.com/InfiniTimeOrg/InfiniTime/blob/develop/doc/buildWithDocker.md
• https://hub.docker.com/repository/docker/pfeerick/infinitime-build

It asks me to log in when I try to view it, so not sure if it's still valid (maybe set private?).

Nevertheless, if a new image needs to be hosted somewhere it could be done in the GitHub registry, no need to create a new DockerHub account. It might be faster as well, but I doubt it will be noticeable.

[ntindle]

IMO I don’t see the problem with building the container with GH Actions then using that container to exec the command just like the docs say

[carlosperate]

Well, it can work, but the way I see it the main issues with running docker as an action from a local Dockerfile would be:

1. The image is build on every CI run, this will be really slow (don't know if GitHub does some caching automagically)
2. A new container would be spin per step, so you don't preserve state and you might end up grouping multiple commands in a single step, which might not be a deal breaker, but it's usually better to separate them

[carlosperate]

If we push an "official" Docker image to DockerHub or GitHub Container Registry, we can also base the current DevContainer and GitPod Dockerfiles on that and avoid a lot of repetition:

• https://github.com/InfiniTimeOrg/InfiniTime/blob/develop/.devcontainer/Dockerfile
• https://github.com/InfiniTimeOrg/InfiniTime/blob/develop/docker/.gitpod.Dockerfile

[ntindle]

1. The image is build on every CI run, this will be really slow (don't know if GitHub does some caching automagically)

Tried this, it doesn't take very long to build at all. (3 mins or so with no caching yet isn't bad for an automated process.)

2. A new container would be spin per step, so you don't preserve state and you might end up grouping multiple commands in a single step, which might not be a deal breaker, but it's usually better to separate them

on:
  [push, pull_request]

jobs:
  build-container:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout source files
        uses: actions/checkout@v2
        with:
          submodules: recursive

      - name: Show files
        run:  set ; pwd ; ls -l
      - name: Build the Docker Container
        run: docker image build -t infinitime-build ./docker
      - name: Run the container
        run: docker run --rm -v  $(pwd):/sources infinitime-build

Other than this yaml file not actually running the commands, couldn't you just exec into the container the commands you want to keep the state?

If we push an "official" Docker image to DockerHub or GitHub Container Registry, we can also base the current DevContainer and GitPod Dockerfiles on that and avoid a lot of repetition:

This is something else I was confused about. We have three separate dockerfiles in the repo with no clear indicator of which is the primary

[oxr463]

What's the current status on this task? Do we have any PRs?

[carlosperate]

Likely implemented here: #1138

@JF002 if that's the case we can close this issue? Or was there anything else that still needs to be done?

[NeroBurner]

Indeed, implemented in #1138
Thanks, and closing