Fix container compatibility with Gitlab CI

[allonhadaya-maven]

This commit updates the default config.containers.shell.entrypoint to execute the startup command with exec rather than as a shell call. This allows Gitlab CI runnners to properly send scripts to CI jobs running the shell container image.

For reference, here's how Gitlab runners bring up a container and run the script:

1.The runner starts a Docker container using the defined entrypoint. The
default from Dockerfile that may be overridden in the .gitlab-ci.yml file.

...

4. The runner sends the script to the container’s shell stdin and receives
   the output.

---

This pattern of integrating with Gitlab CI produces improved latency over the current recommended pattern:

• pipelines build the shell once and then reuse the image in each shell CI job

• pipelines can skip unnecessary build jobs using CI rules

• shell CI jobs only load the shell image, not the large devenv image

  update: shout out to @domenkozar for optimizing the devenv image size ee0fd5c 🚀

• shell CI jobs run script commands as soon as the job container is ready

Users can implement this pattern as follows:

# devenv.nix

{ pkgs, ... }:
{
  env.GREET = "hello";
  packages = [ pkgs.jq ];
  containers.shell = {
    name = "hello-world";
    registry = "docker://my-registry.com/";
  };
}

# .gitlab-ci.yaml

# Build the shell container image and copy it to my-registry.com/hello-world
# Note: defining change rules allows users to skip unnecessary builds

build-devenv-shell:
  stage: build
  image: ghcr.io/cachix/devenv/devenv:v1.6
  script:
    - devenv container
      --copy-args="--dest-creds my-registry-user:$MY_REGISTRY_TOKEN"
      --option containers.shell.version:string "$CI_COMMIT_BRANCH"
      copy shell
  rules:
    - changes:
      - devenv.nix
      - devenv.lock

.devenv-shell:
  image: my-registry.com/hello-world:$CI_COMMIT_BRANCH
  needs:
    - job: build-devenv-shell
      optional: true

# Run CI workloads using the shell container image
# Note: script runs as soon as the job container is ready

greet:
  stage: test
  extends: .devenv-shell
  script:
    - echo $GREET

jq-version:
  stage: test
  script:
    - jq --version

[domenkozar]

See ac2e743 for why bash was used /cc @mcdonc

[allonhadaya-maven]

See ac2e743 for why bash was used /cc @mcdonc

Ah, thanks for providing that context!

This will represent a breaking change for users who currently have startup commands defined like so:

# No longer supported:
{...}:
{
  containers.shell.startupCommand = "if [ 1 = 1 ]; then echo yup; fi";
}

Users who wish to use shell builtins in their startup command should call the shell explicitly:

# Do this instead:
{...}:
{
  containers.shell.startupCommand = "bash -c 'if [ 1 = 1 ]; then echo yup; fi'";
}

I'd recommend moving forward with this breaking change since moving back to exec enables container runtimes to properly supervise the resulting containerized process. See Best practices ENTRYPOINT:

For example, the Postgres Official Image uses the following script as its ENTRYPOINT:

(code block omitted)

This script uses the exec Bash command so that the final running application becomes the container's PID 1. This allows the application to receive any Unix signals sent to the container.

[domenkozar]

Could we: exec bash -c $cmd?

[domenkozar]

@allonhadaya-maven just wondering if that breaks semantics, otherwise I'm +1 for this change!

[allonhadaya-maven]

@allonhadaya-maven just wondering if that breaks semantics, otherwise I'm +1 for this change!

@domenkozar that might work! Towards the end of this week I'll have a chance to test that entrypoint configuration and also follow up with those documentation updates we discussed.

[domenkozar]

ping :)