Docker image: Add support to use as base image in CI/CD jobs

[dnsmichi]

Problem to solve

The Docker image provided with https://hub.docker.com/r/orangeopensource/hurl assumes that the entrypoint always will be /usr/bin/hurl thus not allowing to spawn a shell into the container - like a CI/CD pipeline and job would do.

https://github.com/Orange-OpenSource/hurl/blob/master/contrib/docker/Dockerfile

ENTRYPOINT ["/usr/bin/hurl"] 

Using the container image in GitLab CI/CD runs into weird error messages. The following .gitlab-ci.yml file uses the image as default, and runs a one line script to test hurl. The idea is to override any executed command, and also chain multiple commands for different actions; and/or provide additional commands that upload reports, call the API to add MR comments, etc.

default:
    image: orangeopensource/hurl

hurl-gitlab-com:
    script:
        - echo -e "GET https://hurl.dev\n\nHTTP/1.1 200" | hurl --test --color 

error: hurl: cannot access 'sh': No such file or directory leads into the problem that ENTRYPOINT is always put on the command line, and the GitLab Runner essentially executes

/usr/bin/hurl sh 

to run the container from the image, which won't work.

Pipeline run in https://gitlab.com/everyonecancontribute/dev/hurl-playground/-/commit/888d33906935979a098115ca2db09e4b65bc058e

Workaround

While this behavior is great for standalone container runtimes and containers that do not need supervision, it requires building custom container images for CI/CD pipelines.

For example using the Debian packages in https://gitlab.com/everyonecancontribute/dev/hurl-playground/-/blob/f84daac5aee893f444e8b1026ee8379310c2847e/Dockerfile

# Docker image provided in https://github.com/Orange-OpenSource/hurl/tree/master/contrib/docker does not allow to override the entrypoint for CI/CD, no direct shell access possible.
# Build a custom image instead.

FROM debian:11-slim

ENV DEBIAN_FRONTEND noninteractive

ARG HURL_VERSION=1.8.0

RUN apt update && apt install -y curl jq ca-certificates
RUN curl -LO "https://github.com/Orange-OpenSource/hurl/releases/download/${HURL_VERSION}/hurl_${HURL_VERSION}_amd64.deb"
# Use apt install to determine package dependencies instead of dpkg
RUN apt -y install "./hurl_${HURL_VERSION}_amd64.deb"
RUN rm -rf /var/lib/apt/lists/*

CMD ["hurl"]

The resulting container image then works to build.

# Hurl job template  
.hurl-tmpl:
    image: registry.gitlab.com/everyonecancontribute/dev/hurl-playground:latest 
    variables:
        HURL_URL: gitlab.com
        HURL_JUNIT_REPORT: hurl_junit_report.xml


# Nginx serves HTTP/1.1
hurl-dnsmichi-at:
    extends: .hurl-tmpl
    variables:
        HURL_URL: dnsmichi.at 
    script:
        - echo -e "GET https://${HURL_URL}\n\nHTTP/1.1 200" | hurl --test --color

Proposal

1. Evaluate if changing the ENTRYPOINT attribute in the current Docker image would break existing workflows/docs
2. Evaluate creating a special tagged image that provides a way to specify the entrypoint for CI/CD, i.e. by using CMD ["hurl"] instead.

@ maintainers - If you need access to the GitLab project https://gitlab.com/everyonecancontribute/dev/hurl-playground (or a copy of the same to play and break), please share your GitLab.com SaaS user handle with me, and I'll add you there to make things easier to reproduce :-)

[lepapareil]

Hi @dnsmichi 😀,

Our goal being to have an executable Hurl image we naturally chose the ENTRYPOINT parameter. Indeed as CMD parameter is very used when images are dedicated to ci/cd or when it simply contains several different executables we must take a look at your proposals 👍.

However you can already use the hurl docker image in gitlab cd/cd simply by using gitlab keyword entrypoint: [""] as desribed on https://docs.gitlab.com/ee/ci/yaml/#imageentrypoint, for example:

image: alpine:latest

stages:
  - test

hurl-version:
  stage: test
  image:
    name: ghcr.io/orange-opensource/hurl:latest
    entrypoint: [""]
  script:
    - hurl --version

hurl-from-stdin:
  stage: test
  image:
    name: ghcr.io/orange-opensource/hurl:latest
    entrypoint: [""]
  script:
    - echo -e "GET https://hurl.dev\n\nHTTP/* 200" | hurl --test --color

hurl-from-file:
  stage: test
  image:
    name: ghcr.io/orange-opensource/hurl:latest
    entrypoint: [""]
  script:
    - echo -e "GET https://hurl.dev\n\nHTTP/* 200" > test.hurl
    - hurl --test --color test.hurl

I created an small example project on https://gitlab.com/lepapareil/hurl-gitlab-ci-sample that will be integrated in our doc shortly 😉.

[dnsmichi]

@lepapareil Thanks - @jcamiel was so kind to share the project in our Twitter DM yesterday. I was not aware that the entrypoint override really works in GitLab runner for the image, learned something new and will certainly update the blog post I am writing. For transparency, this is the blog MR: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/115548

The other problem I am running into is the different library dependencies generating different HTTP protocol version responses, discussed in https://gitlab.com/everyonecancontribute/dev/hurl-playground/-/merge_requests/12#note_1203174103 and moving forward with #1077

[dnsmichi]

I created an small example project on https://gitlab.com/lepapareil/hurl-gitlab-ci-sample that will be integrated in our doc shortly 😉.

Let's leave this issue open until the docs PR is ready, and then close it. :)

[dnsmichi]

FYI, I've written a blog post that details more GitLab CI/CD workflows with Hurl, including review app environments. Feel free to include it in your docs PR, or let me know if/how this would fit into the current docs.

https://about.gitlab.com/blog/2022/12/14/how-to-continously-test-web-apps-apis-with-hurl-and-gitlab-ci-cd/

[jcamiel]

@dnsmichi I'm updating the tutorial with link to your post, and I will update it asap with a proper section for GitLab CI/CD (see #1101)

[dnsmichi]

@jcamiel Awesome, thanks a lot!

[jcamiel]

Created a doc issue for GitLab CI/CD integration #1215