Best practices for CI in Gitlab

Hi there,

I want to create a Dockerfile for Gitlab's CI/CD pipeline. For example I have a repository with a simple Plone addon and some test cases which I want to run on every commit. May do you have an example configuration for me which installs Plone 5.2.1, installs my addon and runs my test cases on it?

This is the first time I am doing this. I know how Dockerfiles work but I never did any CI/CD with it. There are example templates for all kinds of programming languages but there is none for Plone addon testing. Does it make sens to use a build from Docker Hub as a base image? Or am I on the wrong path here?

Can you give me some hints or can you point me to a resource which can help me with that, specifically for Plone?


I don't have a best practice, because we are running the testing of our plone addons in the project repositories. Our Gitlab config triggers the project builds on every change in the addon repositories. Maybe this could be a workaround to set up a plone repository for testing your addons.

So you have an already installed Plone running on a different machine and then you trigger a buildout -c develop.cfg or something similar with every commit which in turn tests the new code on that machine?
Or what do you mean with a project repository?

plonecli/ bobtemplates.plone generates a .gitlabci.yml like so

with some basic setup.

I know this template. But it always runs into errors. I guess the first reason is that is uses Python 2.7 and not Python 3.8. But maybe I can try to fix that.

I created a Docker image for running CI tests in gitlab using this guide that was invaluable. For my purposes I didn't bother to use a pre-defined Plone-specific image, I just used centos7 as a base because of our particular environments and installed Plone and dependencies on it, and from that created a buildout using all of our eggs. All of my projects on my company's internal gitlab use this with a .gitlab-ci.yml file to run the tests and a simple buildout config gitlab-ci.cfg. The Docker container itself already has a fully built buildout cache from creating the image, so when you are running tests automatically after a commit it will very quickly create a new buildout using the cached eggs location.

The cfg file is very minimal. The extends location it refers to is defined in the image

extends = /plone5/instance/buildout.cfg
develop = .

# this tells buildout to _not_ use a released version of this package
ims.webdev =

The yml file is also fairly simple. This is the relevant snippet

  - echo "Running buildout"
  - buildout -c gitlab-ci.cfg
  - echo "buildout successful"
  - echo "running test on version:"
  - python --version
  - /builds/$CI_PROJECT_PATH/bin/test -v -s ims.webdev
1 Like

You can try (repository is at It is based on the bobtemplates.plone configuration, but has a lot of dependencies pre-installed (so the docker image is bigger, but that is ok for testing). The default uses Python 3.7, but it supports 2.7 as well. It also has geckodriver installed for robot tests (which always resulted in errors for me when installing on the fly).

1 Like

Wow. That script is gold. It just works.
But there is a small inconvenience.

The command "bin/code-analysis" exited with 1 in 0.396s.
ERROR: Job failed: exit code 1

Is this normal if there are any small issues regarding the coding conventions? Can I just ignore some of these warnings? These are some of the warnings I want to ignore:

E302 expected 2 blank lines, found 1
W293 blank line contains whitespace
E251 unexpected spaces around keyword / parameter equals
E203 whitespace before ':'

Sorry for that dumb question but for now this topic is relatively new to me and I still have a lot to learn.

Glad it works for you. You could check thoses errors before you commit/push (recommended), or disable the return-status-codes in your .gitlabci.yml:

  - buildout -n -c buildout.cfg download-cache=downloads code-analysis:return-status-codes=False

Plone Foundation Code of Conduct