Re: [PATCH v2 1/3] github-actions: run gcc-8 on ubuntu-20.04 image

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 24 2022, Jiang Xin wrote:

> From: Jiang Xin <zhiyou.jx@xxxxxxxxxxxxxxx>
>
> GitHub starts to upgrade its runner image "ubuntu-latest" from version
> "ubuntu-20.04" to version "ubuntu-22.04". It will fail to find and
> install "gcc-8" package on the new runner image.
>
> Change the runner images from "ubuntu-latest" to "ubuntu-20.04" in order
> to run with "gcc-8" as a dependency.

I very much like this direction, as we shouldn't have to scramble to
update our CI every time GitHub switches defaults, and by using "latest"
in general we also break e.g. re-pushes or re-rolls of outstanding topics/PRs.

I.e. you'll push today, it'll work, tomorrow the "latest" image has
changed and your CI breaks, but through no fault of the code you're
testing.

But per previous discussion on this exact topic at least Junio & Derrick
(CC'd) disagreed with going in that direction, see
https://lore.kernel.org/git/220825.865yig4bd7.gmgdl@xxxxxxxxxxxxxxxxxxx/
(and the E-Mail it links to).

Now, I think that if we have some notification so we'll update the
"pinned" image sooner than later it'll address the concerns they had,
but do we have that? I've seen notices from GitHub CI about e.g. some
things in the main.yml file being deprecated, will we get those for
these "pinned" images too in a timely manner?

Because while I think a non-pinned "latest" sucks because it forces us
to scramble with updates like this, having a "pinned" image go away
entirely (because nobody noticed we should update it sooner-than-later)
would suck more.

> Instead of use the environment "$runs_on_pool" as below:
>
>     case "$runs_on_pool" in
>     ubuntu-20.04 | ubuntu-latest)
> 	;;
>
> we can reuse the os field in the matrix, and use a new environment
> "$runs_on_os" as below:
>
>     case "$runs_on_os" in
>     ubuntu)
>         ;;

I think this is probably a good change, as we won't need to
search-replace the image name in as many places in the future.

But let's have this as a seperate change. Here you're just refactoring
the selection behavior of the main.yml + CI lib, it doesn't need to be
bundled up with the change to change the target image.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux