GitLab CI shared-runner compatibility about docker-aspell HOT 4 OPEN

Immediately after spending 2 hours researching this problem and writing the ticket, I happened across rumours of a functioning work-around that delegates to /usr/bin/env and modifies $PATH. I've managed to confirm the following working as intended:

.gitlab-ci.yml:

spellcheck en-US:
  stage: test
  image:
    name: starefossen/aspell:0.60
    entrypoint:
    - "/usr/bin/env"
    - "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
  script:
  - ./spellcheck list

where spellcheck is basically

#!/bin/bash

aspell \
    --encoding 'UTF-8' \
    --mode html \
    --personal './.aspell.en.pws' \
    --lang en-US < README.md

exit 1

with quite a bit more sophistication (actual implementation).

Image id sha256:1d2a35ff9aa9af497e3a424b99b75a156a7234c1dc2a8db8e8d612e8c6941edd.

Given that, and the expectation that eventually GitLab's shared runners will adequately support entrypoint overriding, this ticket probably is not worth pursuing.

from docker-aspell.

It sounds like it would still be quite helpful for you to have a sans ENTRYPOINT version. I'd be happy to make one for you. Although I guess it's up to @Starefossen wants it tied to this repo

from docker-aspell.

I am very sorry for breaking people’s CI pipelines. That was not my intention when merging the change. I think we should revert the entrypoint and make a separate tag with the entrypoint set.

I am away from my workstation, if anyone can propose a PR to revert the entrypoint I can approve it from here.

from docker-aspell.

For what it's worth, our CI didn't break, because we haven't taken this into use yet. You should not feel guilty on my account, and since nobody else has complained I think there was no damage done. We also usually mirror community images we take in precisely to avoid accidents.

I wouldn't mind submitting a change to revert the custom entrypoint but I'm actually not sure that's the best idea on its own: that change is a month old so you'd just risk breaking other people's work flows.

I don't do enough Docker work to know what kind of solution works best long-term but I think if it were up to me I would make 2 Dockerfiles, the one with the custom ENTRYPOINT inheriting from the other and retaining the current tag name. The official Debian images use a variant of this that distinguishes via directories but they also need more scalability. I've also seen a solution that generates a temporary Dockerfile by deleting the ENTRYPOINT at build time.

from docker-aspell.