Renovate: Docker images v14.x doesn't work in gitlab

[Nebulis]

What Renovate type are you using?
Renovate CLI / Docker image

Describe the bug
Running renovate in gitlab with docker images v14.x fails

Did you see anything helpful in debug logs?

Running with gitlab-runner 11.7.0-rc1 (6e20bd76)
  on docker-auto-scale 0277ea0f
Using Docker executor with image renovate/renovate:14.0.0 ...
Pulling docker image renovate/renovate:14.0.0 ...
Using docker image sha256:13898761dcab4398a1dacf94661e622e6646a1ac94b88cf322401765fc2d7a62 for renovate/renovate:14.0.0 ...
Running on runner-0277ea0f-project-8103921-concurrent-0 via runner-0277ea0f-srm-1548681790-4a9be702...
Cloning repository...
Cloning into '/builds/mycf.sg/renovate'...
Checking out 50f424c1 as master...
Skipping Git submodules setup
sh: 1: set: Illegal option -o pipefail
sh: 1: set: Illegal option -o pipefail
ERROR: Job failed: exit code 2

To Reproduce
renovate.json:

{
  "extends": [
    "config:base"
  ],
  "automerge": false,
  "commitMessagePrefix": "feat:",
  "endpoint": "https://gitlab.com/api/v4/",
  "labels": [
    "Bot"
  ],
  "repositories": [{
    "repository": "mycf.sg/ui-employer"
  }],
  "pinVersions": true,
  "platform": "gitlab",
  "prConcurrentLimit": 0,
  "prHourlyLimit": 0,
  "recreateClosed": true
}

gitlab-ci.yml

stages:
  - renovate

variables:
  RENOVATE_CONFIG_FILE: "${CI_PROJECT_DIR}/renovate.json"

renovate:
  stage: renovate
  image:
    name: renovate/renovate:14.0.0
    entrypoint: ["/bin/sh", "-c"]
  script:
    - node /usr/src/app/lib/renovate.js --log-level debug # Overwrite entrypoint as it doesnt work if not overwriting.

Expected behavior
I expect renovate to run

Additional context
Docker image v 13.180.0 works well

[rarkins]

Please try with the latest 14.x and not 14.0.0, let me know if there's any difference to the logs

[rarkins]

Actually this is non-standard:

renovate:
  stage: renovate
  image:
    name: renovate/renovate:14.0.0
    entrypoint: ["/bin/sh", "-c"]
  script:
    - node /usr/src/app/lib/renovate.js --log-level debug # Overwrite entrypoint as it doesnt work if not overwriting.

Please revert back to the normal way of running Renovate and post logs from that.

[Nebulis]

I tried latest and other version (14.2.0, 14.1.0) and got the same result.

What's the normal way ?

[rarkins]

The normal way is not to override the image's entrypoint. Doing so is the docker equivalent of monkey patching code. Please remove that and post the new logs.

[Nebulis]

I did that a while ago because gitlab requires the script attribute and if I remember that using ["node", "/usr/src/app/lib/renovate.js"] as entrypoint didn't work (I can't remember why) and I also got issues passing down variables.

There is also no way (AFAIK) to pass extra parameters to the entrypoint without redefining it in the stage.

I will try without overriding the entrypoint to see if it runs at least

[Nebulis]

renovate:
  stage: renovate
  image: 
    name: renovate/renovate
  script:
    - echo "Hello world"

With this, renovate is run twice, and I don't know how to pass down parameters.

I found another way to override docker entrypoint from https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#overriding-the-entrypoint-of-an-image:

renovate:
  stage: renovate
  image: 
    name: renovate/renovate
    entrypoint: [""]    
  script:
    - node /usr/src/app/lib/renovate.js --token $GITLAB_TOKEN

This works, anyway as you pointed out this is not a good way. As I was able to fix my issue, I think the issue can be closed. If anyone knows a better way to run renovate images in gitlab, please let me know :pray:

[rarkins]

What if you just use environment parameters to configure Renovate instead of CLI parameters? That way I'd hope you don't need to override entrypoint. Is script even needed?

e.g. RENOVATE_PLATFORM, RENOVATE_TOKEN, RENOVATE_AUTODISCOVER, etc.

[Nebulis]

I could (I was actually looking for how to replace GITLAB_TOKEN which is deprecated).

I still have the issue that it's run twice. I will check it they are run sequentially or in parallel. Will let you know :+1:

[Nebulis]

I tried with the following gitlab-ci.yml

renovate:
  stage: renovate
  image: 
    name: renovate/renovate
  script:
    - echo "Hello world"

which results in

ERROR: Repository is not found (repository=sh)

In the logs I can see

DEBUG: CLI config
       "config": {"repositories": ["sh"]}

Which I understand that sh is passed as argument by gitlab and renovate try to run with this repository.

[rarkins]

Either you're not sharing your whole config above, or your config is incomplete.

1. You need to configure Renovate using env variables, you are not showing any there, e.g. platform, token, autodiscover
2. I don't know what GitLab's rules are for script, but any script seems like a mistake to me

[Nebulis]

Everything is available there => https://gitlab.com/mycf.sg/renovate (I should have linked before)

Environment variables set are:

• GITHUB_COM_TOKEN
• LOG_LEVEL
• RENOVATE_CONFIG_FILE
• RENOVATE_TOKEN

The error ERROR: Repository is not found (repository=sh) is actually the one I met when I set up renovate a while ago.

I don't know what GitLab's rules are for script, but any script seems like a mistake to me

I agree :smile:

IMHO the issue is not related to renovate (If I run locally it's working well). Annoying part is my configuration breaking from v13 to v14 but I found a workaround.

[rarkins]

Are you also setting RENOVATE_PLATFORM? And are you intending to just Renovate one repo, or multiple? For multiple you'd need RENOVATE_AUTODISCOVER=true too. Unless of course you put those in your config file.

I think there might be a firewall blocking me from your repo btw.

FYI Renovate takes the first non-url param as a repository name, e.g. you usually run it like renovate facebook/jest to Renovate the facebook/jest repo. So if you or GitLab indirectly are running the container like renovate sh -c "echo world" then that would explain why Renovate thinks you're trying to access repo sh.

In v14 Renovate changed from an alpine-based image to an Ubuntu-based one. The way it "normally" runs should have stayed the same (e.g. from command line) but it sounds like the way it runs within GitLab CI could have changed.

[Jamesking56]

If it helps at all, I'm doing the same thing running the docker image via GitLab CI and I don't have any issues.

Here is my .gitlab-ci.yml file:

image: docker:latest

services:
  - docker:dind

stages:
  - renovate

renovate:
  stage: renovate
  script:
    - docker pull renovate/renovate:latest
    - docker run renovate/renovate:latest --host-rules="<SNIP>" --platform gitlab --timezone Europe/London --token $RENOVATE_TOKEN --autodiscover --log-level debug --print-config true
  only:
    - master

Then I just set RENOVATE_TOKEN CI variable for my renovate bot user's personal access token.

[Jamesking56]

@rarkins maybe its worth adding my code to the readme?

[rarkins]

@Jamesking56 yes, it would be great if you can submit a PR to the self hosting doc. I think the main difference seems to be that you're running renovate indirectly within dind rather than directly. It sounds like GitLab tries to run "scripts" using sh or something like that, whereas Renovate is just expecting its CLI arguments.

[Nebulis]

I updated the link to the repository (pasted wrong one).

I don't use RENOVATE_PLATFORM, it's already set in renovate.json. I don't use RENOVATE_AUTODISCOVER as well. It's working well but it's too powerful, I want to limit for the moment the repositories using renovate.

So if you or GitLab indirectly are running the container like renovate sh -c "echo world" then that would explain why Renovate thinks you're trying to access repo sh.

I think that's the case and that explains well the error. This error was also trigger with v13 docker images and that's why I used a solution to override the entrypoint.
I've seen the changes (from alpine to ubuntu) and I can't explain why my previous configuration is not compatible with the new images. According to gitlab documentation (https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#overriding-the-entrypoint-of-an-image) it should depends on docker version, so it shouldn't be impacted by moving the docker image from alpine to ubuntu.

I think we can close the issue, or would you like to dig further ? (edit, already closed :grimacing:)

Note: Thanks for dind sharing, I tried to avoid using it as much as I can, in that case it makes things cleaner :+1:

[rarkins]

@Nebulis Thanks for the feedback. If/once you find a config for running via GitLab CI directly (without dind) then it would definitely be great if you can add it to the self hosting doc in this repo. I think the key here is how GitLab CI uses "scripts" as a replacement for the traditional "cmd" in Docker.