GitLab CI: make sure only official docker images are used to run pipeline jobs

[Denis Konovalyenko]

This is the original thread.

Make sure only official docker images are used to run pipeline jobs.

Minify the total amount of downloads and actions to take during the execution of a job if applicable.

[Denis Konovalyenko]

Traverse the solution to all projects which are integrating with GitLab.

[Mihai Nita]

What do you think about this: use a single image "statement" like this:

“You can simply define an image that will be used for all jobs and a list of services that you want to use during build time:”

https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#define-image-and-services-from-gitlab-ciyml

---

Kind of related (Docker) I had / have a few other ideas:

Start from openjdk, not maven

Seem to have more control and options: Maven: 3.6.0-jdk-8-<platform>, 3.6-jdk-8-<platform>, 3-jdk-8-<platform>, platform : alpine / slim Openjdk: has Java sub-versions (8u171, 8u181, ...) and more platforms (stretch / alpine, full / slim)

And I think it is more important to control the Java version than the maven version.

When using openjdk we can either install the default maven / ant (apt-get), or download - unpack whatever version we want See for instance https://bitbucket.org/nmihai_2000/fake_okapi/src/dev/codeship_tools/install_tools.sh

---

Build the image from a Dockerfile, post that image to GitLab, and use it for all the jobs in yaml

So the Dockerfile can do all the apt-get, tools install and configurations.

Pros: Would be easier to test locally (build docker from Dockerfile and run things in it)

Now if I want to play with the image I have to change the yaml, push, and then fails in GitLab because I had a typo. Or the gpg import command was not quite right. Or I make a Dockerfile locally, check that it works, then copy the commands from the Dockerfile to the yaml config, including the change of syntax (RUN foo in Dockerfile becomes script: - foo in yaml, etc.)

Also reduces the scripts to keep in sync. We create one image and we build everything with it. Otherwise we need to keep in sync between Okapi, Xliff Toolkit, Integration, maybe in the future Reports, builds with Java 8 and 11 ...

Cons: Harder to publish (you have to do it locally, then publish it to the GitLab registry) Not too hard, but still... I did it yesterday.

Basically you do a docker login registry.gitlab.com then the normal docker build and docker run until it all works the way you want, and in the end you do a docker push

The login and push are the only extras compared to working with Docker locally.

---

What do you think?

[Mihai Nita]

BTW, I can take some of the issues that we agreed on, you don't have to keep everything :-)

[Denis Konovalyenko]

@nmihai_2000 , thanks for the additional info!

Regarding the single image statement usage, I think we may end up with this kind of approach if the status stage becomes obsolete after we finalise the multiple builds way in the #25.

I agree with starting from the openjdk and probably have different jobs for building under all supported platforms (linux, mac, windows etc.) and JREs, but this seems to be out of scope for this issue. Could you please post a new one on this?

As for the own docker file, if we just build all required tools and configurations, which are not sensible for exposing to the public, then I would give it a try (still have not got enough time to feel the pros vs cons). Let's create a separate issue for this as well.

If you like to get this one on, please feel free to do so. I have not started it yet.

[Mihai Nita]

Created "enhancement" issues (things work "as is", no real pressure to do this before December 15)

• #31: GitLab CI: Build the image from a Dockerfile, post that image to GitLab, and use it for all the jobs in yaml
• #32: GitLab CI: Start docker image from openjdk not maven

[Denis Konovalyenko]

The pull request #12 has been created.

[Denis Konovalyenko]

The pull request #12 has been merged.