Use a Fedora image with nodejs as the default image for Actions runners

adamwill commented

2026-01-05 23:55:00 +00:00

If you try Forgejo Actions on the staging instance and don't specify a container image, you get a Debian Bookworm image. This doesn't seem in the spirit of things :)

We should probably make our default image a Fedora one. We could just use unmodified https://quay.io/repository/fedora/fedora latest, but there is a problem with that. Probably the most commonly-used action is checkout, and that doesn't work in a stock Fedora container because it doesn't have nodejs in it. So we might want to use an image with nodejs built-in, otherwise 95% of actions will have to do a dnf install nodejs step before running the checkout action, which would be much less efficient than just having it baked into the image.

If you try Forgejo Actions on the staging instance and don't specify a container image, you get a Debian Bookworm image. This doesn't seem in the spirit of things :) We should probably make our default image a Fedora one. We could just use unmodified https://quay.io/repository/fedora/fedora `latest`, but there is a problem with that. Probably the most commonly-used action is `checkout`, and that doesn't work in a stock Fedora container because it doesn't have nodejs in it. So we might want to use an image with nodejs built-in, otherwise 95% of actions will have to do a `dnf install nodejs` step before running the `checkout` action, which would be much less efficient than just having it baked into the image.

lenkaseg self-assigned this

2026-01-07 12:00:58 +00:00

lenkaseg removed their assignment

2026-01-08 11:47:53 +00:00

hricky was assigned by lenkaseg

2026-01-08 11:47:54 +00:00

ryanlerch added this to the Backlog project

2026-01-12 10:15:19 +00:00

ryanlerch modified the project from Backlog to Sprint 12

2026-01-13 05:39:07 +00:00

lenkaseg added the

labels

2026-01-13 10:48:12 +00:00

lenkaseg commented

2026-01-15 11:59:42 +00:00

Member

Discussed this issue with @humaton:

let's host the image definition in forge.fedoraproject.org/forge organization
let's place the image in quay/fedora namespace

Actually, looking into the fedora namespace on quay, I can see several fedora based images with nodejs, for example this one:
https://quay.io/repository/fedora/nodejs-24

We could test whether this image would be suitable.

Discussed this issue with @humaton: - let's host the image definition in forge.fedoraproject.org/forge organization - let's place the image in quay/fedora namespace Actually, looking into the fedora namespace on quay, I can see several fedora based images with nodejs, for example this one: https://quay.io/repository/fedora/nodejs-24 We could test whether this image would be suitable.

siosm commented

2026-01-23 13:49:33 +00:00

So the source for https://quay.io/repository/fedora/nodejs-24 are in https://github.com/sclorg/s2i-nodejs-container and the images is built on GitHub using GitHub Actions: https://github.com/sclorg/s2i-nodejs-container/actions.

I had asked in https://github.com/sclorg/welcome/issues/10 about the status of those images because those are in the Fedora namespace but are neither hosted nor built on Fedora controlled infrastructure.

It might be good to clarify that before we start making a wider use of those images.

CC @pkubatrh @phracek

So the source for https://quay.io/repository/fedora/nodejs-24 are in https://github.com/sclorg/s2i-nodejs-container and the images is built on GitHub using GitHub Actions: https://github.com/sclorg/s2i-nodejs-container/actions. I had asked in https://github.com/sclorg/welcome/issues/10 about the status of those images because those are in the Fedora namespace but are neither hosted nor built on Fedora controlled infrastructure. It might be good to clarify that before we start making a wider use of those images. CC @pkubatrh @phracek

hricky commented

2026-01-23 13:54:16 +00:00

Collaborator

@siosm See https://forge.stg.fedoraproject.org/playground/fedora-runner-experimental and https://github.com/GitHubAtomLearn/fedora-forge-runner

👍 2

hricky commented

2026-01-23 14:06:54 +00:00

Collaborator

AFAIK, the Forge team will create a runner with this image as a default and we can experiment with it on staging.

👍 2

hricky commented

2026-01-23 14:15:00 +00:00

Collaborator

I just did a test with today's build:
https://forge.stg.fedoraproject.org/playground/fedora-runner-experimental/actions/runs/80/jobs/0/attempt/1

I also did some experiments and tests and I don't think the NodeJS 24 minimal container image is suitable for our specific needs. I also doubt that the "standard" Node.JS 24 S2I base image will be any different. See https://forge.stg.fedoraproject.org/playground/fedora-runner-experimental/actions/runs/81/jobs/0/attempt/1

I just did a test with today's build: https://forge.stg.fedoraproject.org/playground/fedora-runner-experimental/actions/runs/80/jobs/0/attempt/1 I also did some experiments and tests and I don't think the NodeJS 24 minimal container image is suitable for our specific needs. I also doubt that the "standard" Node.JS 24 S2I base image will be any different. See https://forge.stg.fedoraproject.org/playground/fedora-runner-experimental/actions/runs/81/jobs/0/attempt/1

👍 2

humaton modified the project from Sprint 12 to Sprint 13

2026-01-26 10:20:20 +00:00

lenkaseg commented

2026-02-03 15:30:50 +00:00

Member

Fedora-based runner defined by @hricky deployed to staging under the playgroung org, callable by fedora1.1

Fedora-based runner defined by @hricky deployed to staging under the playgroung org, callable by `fedora1.1`

👍 1

hricky commented

2026-02-03 15:51:48 +00:00

Collaborator

Some initial tests:
https://forge.stg.fedoraproject.org/playground/runner-image-test/actions?workflow=test_fedora1.1_image.yaml&actor=0&status=0
https://forge.stg.fedoraproject.org/playground/fedora-runner-experimental/actions?workflow=fedora-runner-1.1-test.yaml&actor=0&status=0

Some initial tests: https://forge.stg.fedoraproject.org/playground/runner-image-test/actions?workflow=test_fedora1.1_image.yaml&actor=0&status=0 https://forge.stg.fedoraproject.org/playground/fedora-runner-experimental/actions?workflow=fedora-runner-1.1-test.yaml&actor=0&status=0

ryanlerch modified the project from Sprint 13 to Backlog

2026-02-09 10:50:33 +00:00

walters commented

2026-02-10 19:37:01 +00:00

The idea of having "a default image" for a global CI system I think is one that should probably go away in favor of having projects explicitly pick one. Of course there can be a set of recommended ones.

hricky commented

2026-02-10 22:10:10 +00:00

Collaborator

If we currently define the following workflow:

...
jobs:
  test:
    runs-on: fedora-1
    container:
      image: quay.io/fedora/fedora:latest
    steps:
    ...

We get:

...
workflow prepared
🚀  Start image=quay.io/fedora/fedora:latest
  🐳  docker pull image=quay.io/fedora/fedora:latest platform= username= forcePull=false
  ...

However, if we only define:

...
jobs:
  test:
    runs-on: fedora-1
    steps:
    ...

We get:

...
workflow prepared
🚀  Start image=node:22-bookworm
  🐳  docker pull image=node:22-bookworm platform= username= forcePull=false
  ...

At least as far as I understand and have tested it, each team/project/repo can pick whatever image they need, but if they haven't explicitly chosen one, "the default image" is node:22-bookworm. I think the point here is to replace the Debian-based image that is currently pulled by default in Fedora Forge runners with one based on Fedora.

If we currently define the following workflow: ``` ... jobs: test: runs-on: fedora-1 container: image: quay.io/fedora/fedora:latest steps: ... ``` We get: ``` ... workflow prepared 🚀 Start image=quay.io/fedora/fedora:latest 🐳 docker pull image=quay.io/fedora/fedora:latest platform= username= forcePull=false ... ``` However, if we only define: ``` ... jobs: test: runs-on: fedora-1 steps: ... ``` We get: ``` ... workflow prepared 🚀 Start image=node:22-bookworm 🐳 docker pull image=node:22-bookworm platform= username= forcePull=false ... ``` At least as far as I understand and have tested it, each team/project/repo can pick whatever image they need, but if they haven't explicitly chosen one, "the default image" is `node:22-bookworm`. I think the point here is to replace the Debian-based image that is currently pulled by default in Fedora Forge runners with one based on Fedora.

👍 1

lenkaseg commented

2026-02-11 08:18:02 +00:00

Member

@walters wrote in #332 (comment):

The idea of having "a default image" for a global CI system I think is one that should probably go away in favor of having projects explicitly pick one. Of course there can be a set of recommended ones.

You mean to remove the default image entirely?
We can test it, if it's possible to register a runner without a default image and force the users to pick some.

What would be the benefit?

@walters wrote in https://forge.fedoraproject.org/forge/forge/issues/332#issuecomment-379478: > The idea of having "a default image" for a global CI system I think is one that should probably go away in favor of having projects explicitly pick one. Of course there can be a set of recommended ones. You mean to remove the default image entirely? We can test it, if it's possible to register a runner without a default image and force the users to pick some. What would be the benefit?

ngompa commented

2026-02-11 09:42:12 +00:00

I don't think there's that much of a benefit for the ergonomic annoyance that would cause.

humaton commented

2026-02-12 10:46:20 +00:00

Owner

@walters wrote in #332 (comment):

The idea of having "a default image" for a global CI system I think is one that should probably go away in favor of having projects explicitly pick one. Of course there can be a set of recommended ones.

I agree that projects should be able to explicitly choose their own images. However, I think we should still provide a general-purpose runner by default so that users can run Forgejo Actions out of the box.
CI is not necessarily the primary use case we’re targeting, and projects with specific requirements can define their own image.

@walters wrote in https://forge.fedoraproject.org/forge/forge/issues/332#issuecomment-379478: > The idea of having "a default image" for a global CI system I think is one that should probably go away in favor of having projects explicitly pick one. Of course there can be a set of recommended ones. I agree that projects should be able to explicitly choose their own images. However, I think we should still provide a general-purpose runner by default so that users can run Forgejo Actions out of the box. CI is not necessarily the primary use case we’re targeting, and projects with specific requirements can define their own image.

👍 1

walters commented

2026-02-12 14:53:46 +00:00

Here's a different but related mistake I think this is making:

callable by fedora1.1

What specific Fedora version is "1.1"? Presumably it floats to "latest stable"? That's going to be guaranteed to cause breakage every 6 months for nontrivial usage.

Trying to have a "default CI image" has exactly the same problem as Github has with "ubuntu-latest": check https://github.com/actions/runner-images/issues/10636 which they backed off on because the absolutely huge fallout of them actually changing what it means. Still to this day ubuntu-latest is not the latest, it's now ubuntu-24.04 that one has to opt in to...

And yeah "fedora1.1" has some versioning included, but what's the meaning of the "1" there specifically?

Here's a different but related mistake I think this is making: > callable by fedora1.1 What specific Fedora version is "1.1"? Presumably it floats to "latest stable"? That's going to be guaranteed to cause breakage every 6 months for nontrivial usage. Trying to have a "default CI image" has exactly the same problem as Github has with "ubuntu-latest": check https://github.com/actions/runner-images/issues/10636 which they backed off on because the absolutely huge fallout of them *actually* changing what it means. Still to this day `ubuntu-latest` is not the latest, it's now `ubuntu-24.04` that one has to opt in to... And yeah "fedora1.1" has some versioning included, but what's the meaning of the "1" there specifically?

adamwill commented

2026-02-12 16:26:02 +00:00

Author

OTOH, not providing a latest image causes breakage for other usage. Personally I prefer to set my CI to run on 'latest' and then fix problems when they come up, than have to deal with bumping it manually every six months for every repo I own (I have to do this for Python versions in tox, and the result is that I often don't and then I notice three years later I'm mostly testing on EOL pythons). And AFAIK we don't have dependabot or anything like that here (yet?)

I think it's a function of how many projects you maintain and how active and complex they are. If you have a few very active projects with complex CI setups, yes, you probably want to be very picky with this. If you have a lot of not very complex, not very active projects (like me) you might rather be 'sloppy'.

Note, the way this works is that runners have labels, that's what fedora1.1 is. It's a many:many relationship - runners can have as many labels as you like, and the same label can be applied to as many runners as you like. So this really isn't a big problem, we can apply release number labels to runners and apply a latest label to the runners currently on the most recent Fedora and apply any other labels we like for any other reasons.

OTOH, *not* providing a latest image causes breakage for other usage. Personally I prefer to set my CI to run on 'latest' and then fix problems when they come up, than have to deal with bumping it manually every six months for every repo I own (I have to do this for Python versions in tox, and the result is that I often don't and then I notice three years later I'm mostly testing on EOL pythons). And AFAIK we don't have dependabot or anything like that here (yet?) I think it's a function of how many projects you maintain and how active and complex they are. If you have a few very active projects with complex CI setups, yes, you probably want to be very picky with this. If you have a lot of not very complex, not very active projects (like me) you might rather be 'sloppy'. Note, the way this works is that runners have labels, that's what `fedora1.1` is. It's a many:many relationship - runners can have as many labels as you like, and the same label can be applied to as many runners as you like. So this really isn't a big problem, we can apply release number labels to runners *and* apply a latest label to the runners currently on the most recent Fedora *and* apply any other labels we like for any other reasons.

lenkaseg commented

2026-02-12 16:56:30 +00:00

Member

@walters wrote in #332 (comment):

And yeah "fedora1.1" has some versioning included, but what's the meaning of the "1" there specifically?

Ah, that just means @hricky 's updated Containerfile, which we use to experiment with the image, that's no official versioning. We deployed one runner with fedora-based image as a default image in staging, to experiment with. It's accessible by only the playground org there, so definitely not for use outside of there. When/if it's gonna be deployed to production, it's gonna be versioned and labeled.

@walters wrote in https://forge.fedoraproject.org/forge/forge/issues/332#issuecomment-392459: > > And yeah "fedora1.1" has some versioning included, but what's the meaning of the "1" there specifically? Ah, that just means @hricky 's updated Containerfile, which we use to experiment with the image, that's no official versioning. We deployed one runner with fedora-based image as a default image in staging, to experiment with. It's accessible by only the playground org there, so definitely not for use outside of there. When/if it's gonna be deployed to production, it's gonna be versioned and labeled.

Rows
Columns

Use a Fedora image with nodejs as the default image for Actions runners #332