GitLab Integration documentation

[jvacek]

Summary

Documentation for GitLab integration, reliant on the new tags introduced in #6053

Test Plan

[zanieb]

Thanks! I'll be on vacation until Tuesday but will review this then. Exciting to see it.

[jvacek]

Compared to the GitHub guide, I've removed stuff that I believe is irrelevant to a GitLab deployment. Features like Matrices are well documented in GitLab docs, and using uv inside of a container should be pretty evident from the first example.

I did leave in the caching, as that seemed like an obvious "default" thing to have implemented.

I also had to add the md file to the ignore of prettier, as it kept trying to re-format my yaml codeblocks, which would not work if someone wanted to copy-paste them.

[paatre]

Great to see this being documented.

That said, I tried your documented example in my GitLab CI configuration:

variables:
  UV_VERSION: 0.4
  PYTHON_VERSION: 3.12
  BASE_LAYER: alpine

stages:
  - foo

bar:
  stage: foo
  image: 
    name: ghcr.io/astral-sh/uv:$UV_VERSION-python$PYTHON_VERSION-$BASE_LAYER
  script: 
    - run main.py

But the job still fails on the sh not being recognized by the container:

Using docker image sha256:f92e1aa098053d32da4d6ff0a0bc60ca74454153fac4b72ac501f95370e3f4a4 for ghcr.io/astral-sh/uv:0.4-python3.12-alpine with digest ghcr.io/astral-sh/uv@sha256:71a178e0a86e3cd35f55e22a854ec862ceecdb36e9d6664c90e6e9df7f714965 ...
error: unrecognized subcommand 'sh'
Usage: uv [OPTIONS] <COMMAND>
For more information, try '--help'.

Is there something I'm doing wrong or what?

[zanieb]

The container entrypoint is set to uv xref #7030

Looks like it's trying to run uv sh.

[paatre]

The container entrypoint is set to uv xref #7030

Looks like it's trying to run uv sh.

Yeah, that was it. I continued to read the docs and there's two occations regarding the shell:

1. Image requirements: https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#image-requirements
2. Explanation of how the runner starts with Docker containers: https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#override-the-entrypoint-of-an-image.

It's pretty obvious now that uv is the default ENTRYPOINT for the container and sh is the default CMD by GitLab. So the script is given to sh and it's being passed to uv, and that leads to problems.

I just need to override the entrypoint as you've also described in #7030. I kind of understand both sides of the coin:

• I want to have consistent experience on all images
• I want to use images easily without extra container configurations on CI

So yeah, which one is the main driver here is a good question.

[paatre]

Lol, why didn't I think of this: #7030 (comment)

That would have been an even better solution, at least in my very simple use case. The downside with using CMD with the default uv entrypoint is that the script doesn't work if you need or want it in the pipeline.

[samypr100]

@paatre 0.4.6 (once released) will have the behavior you were looking for

[jvacek]

Re-tested with 0.4.9, did I miss any to-dos?

[zanieb]

Thanks! Sorry about the delay here.