Re: [PATCH] ci/github: add missing 'CI_JOB_IMAGE' env variable

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 21, 2025, 07:51 UTC
Message-ID: <xmqqsen6vn1q.fsf@gitster.g>
In-Reply-To: <20250319163328.525284-1-karthik.188@gmail.com>

Karthik Nayak <karthik.188@gmail.com> writes:

> The CI setups of GitLab and GitHub use a common dependency management
> script 'ci/install-dependencies.sh'. The script install the necessary
> packages based on a combination of the "$distro" and "$jobname" env
> variables.

It seems that CI_JOB_IMAGE is a GitLab invention that is defined automatically for all CI/CD jobs?

The range of values for the variable seems to be names of Docker images, so presumably they mean the same thing when used in GitHub Actions environment? I am just idly wondering if ci/*.sh scripts running in GitLab CI/CD says "Ah, we are using ubuntu-latest image" and does one thing, if it is always safe and sensible to do the same thing in GitHub Actions environment when CI_JOB_IMAGE is set to the same 'ubuntu-latest' value in this workflows/main.yml file for the job (otherwise our desire to share as much as possible becomes harder to achieve).

Show 15 quoted lines

> The "$distro" variable is derived from the "CI_JOB_IMAGE" env variable
> set by the CI configs. In the GitHub CI config, some of the jobs are
> missing this variable. For the 'Documentation' job which depends on
> 'meson' being installed, this raises an error since the 'meson'
> dependency is never installed.
>
> Fix this by adding the 'CI_JOB_IMAGE' variable to all missing jobs. We
> don't add it the windows jobs, since they manager their dependency as
> part of the CI config and no further dependency management is needed.
>
> Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
> ---
>
> Junio, not sure if you wanted a patch here, since you already had a fix
> yourself. But I'm providing one nonetheless, feel free to drop it.

Good. The one I did was an attempt to blindly sweep the issue under the rug by patching merely one thing, and I consider that this patch is the true fix for the root issue, so the other one can be reverted out of 'next' (or removed from 'next' when it is rebuilt).

Thanks, will queue.