atomic-desktops/config
4
0
Fork 4
Code Issues Pull requests 8 Activity Actions

POC: Forgejo actions with testing-farm/tmt #757

Closed
lecris wants to merge 17 commits from ci/_atomic-desktops-config:testing-farm into main
pull from: ci/_atomic-desktops-config:testing-farm
merge into: atomic-desktops:main
Conversation 31 Commits 17 Files changed 8 +73 -134
lecris commented 2026-05-06 08:33:12 +00:00
First-time contributor
Copy link

As per forge/forge#364 (comment), here is a proof of concept for the zuul migration to tmt. There are of course missing components and failing tests as things like test duration, hardware setup, run environment, etc. need to be figured out. The example CI state can be seen in https://forge.fedoraproject.org/ci/_atomic-desktops-config/actions

As per https://forge.fedoraproject.org/forge/forge/issues/364#issuecomment-697394, here is a proof of concept for the zuul migration to tmt. There are of course missing components and failing tests as things like test duration, hardware setup, run environment, etc. need to be figured out. The example CI state can be seen in https://forge.fedoraproject.org/ci/_atomic-desktops-config/actions
lecris force-pushed testing-farm from 7cedb1e637 to 309e2d8fe0 2026-05-06 09:41:28 +00:00 Compare
siosm commented 2026-05-06 12:44:57 +00:00
Owner
Copy link

Thanks! Can we run things as root in testing-farm jobs?

Thanks! Can we run things as root in testing-farm jobs?
siosm reviewed 2026-05-06 12:46:44 +00:00
.forgejo/workflows/tests.yaml Outdated
@ -0,0 +17,4 @@
steps:
- uses: https://forge.fedoraproject.org/ci/testing-farm@main
with:
api_key: ${{ secrets.TESTING_FARM_API_TOKEN }}
siosm commented 2026-05-06 12:46:44 +00:00
Owner
Copy link

Do I need to setup something here?

Do I need to setup something here?
lecris commented 2026-05-06 13:36:56 +00:00
Author
First-time contributor
Copy link

Yes indeed so, besides the configuring runs-on for the specifics of the repo, I think this is the only other thing needed to get started and experimenting.

The token you can get from https://testing-farm.io/tokens/

Is the doc at https://docs.testing-farm.io/Testing%20Farm/0.1/onboarding.html what I should read/follow?

That document is good, but just get a token should be all the context needed. Interfacing with testing-farm would be in either https://forge.fedoraproject.org/ci/testing-farm or the plans.fmf

Yes indeed so, besides the configuring `runs-on` for the specifics of the repo, I think this is the only other thing needed to get started and experimenting. The token you can get from https://testing-farm.io/tokens/ > Is the doc at https://docs.testing-farm.io/Testing%20Farm/0.1/onboarding.html what I should read/follow? That document is good, but just get a token should be all the context needed. Interfacing with testing-farm would be in either https://forge.fedoraproject.org/ci/testing-farm or the `plans.fmf`
siosm commented 2026-05-07 09:50:43 +00:00
Owner
Copy link

I've added the token to this repo.

I've added the token to this repo.
siosm marked this conversation as resolved
siosm reviewed 2026-05-06 12:46:59 +00:00
.forgejo/workflows/tests.yaml Outdated
@ -0,0 +13,4 @@
jobs:
testing-farm:
runs-on: docker
siosm commented 2026-05-06 12:46:59 +00:00
Owner
Copy link

Hum, OK, we need a privileged container here. Can we do that?

Hum, OK, we need a privileged container here. Can we do that?
lecris commented 2026-05-06 13:33:01 +00:00
Author
First-time contributor
Copy link

That is fine. This is just the runner that is calling testing-farm cli. It will need to be updated to the runner that you will get enabled on atomic-desktops group. This runner can be super minimal because of that since its only job here is to do a curl post and wait for response, all the rest is done in testing-farm and configured in the ci/plans.fmf

That is fine. This is just the runner that is calling [testing-farm cli](https://gitlab.com/testing-farm/cli). It will need to be updated to the runner that you will get enabled on `atomic-desktops` group. This runner can be super minimal because of that since its only job here is to do a curl post and wait for response, all the rest is done in testing-farm and configured in the `ci/plans.fmf`
siosm commented 2026-05-06 21:23:24 +00:00
Owner
Copy link

Ah yes, makes sense.

Ah yes, makes sense.
siosm marked this conversation as resolved
siosm commented 2026-05-06 12:48:36 +00:00
Owner
Copy link

Is the doc at https://docs.testing-farm.io/Testing%20Farm/0.1/onboarding.html what I should read/follow?

Is the doc at https://docs.testing-farm.io/Testing%20Farm/0.1/onboarding.html what I should read/follow?
lecris commented 2026-05-06 13:30:14 +00:00
Author
First-time contributor
Copy link

Thanks! Can we run things as root in testing-farm jobs?

Yes, on testing-farm you are in either a container/vm/bare-metal machine as root user by default. I am pretty sure it is a root user, and not a privileged user.

> Thanks! Can we run things as root in testing-farm jobs? Yes, _on testing-farm_ you are in either a container/vm/bare-metal machine as root user by default. I am pretty sure it is a root user, and not a privileged user.
lecris reviewed 2026-05-06 13:47:26 +00:00
.forgejo/workflows/tests.yaml Outdated
@ -0,0 +5,4 @@
on:
push:
pull_request_target:
lecris commented 2026-05-06 13:47:26 +00:00
Author
First-time contributor
Copy link

The triggers here are important to consider, let me break down the state that they describe:

  • pull_request_target: runs on a pull request with the contents of .forgejo/workflows/tests.yaml that is in main. This is the only pull request method supported because of how forgejo handles secrets differently from Github (secrets are not available in pull_request mode on forgejo)
  • push: run it on any commit pushes, and it duplicates the runs when run in a PR. branches should be set here to limit the execution, but I am not sure how it should be setup here. I left it without any branches also to debug on my side, but it should definitely be changed

One thing I want to highlight as a consequence of this is that if you even need to update this, you will not see the live results of the changes in a PR. Best workflow to mitigate that is to also run on a well-defined branch name and use that as run through on.push flow.

The triggers here are important to consider, let me break down the state that they describe: - `pull_request_target`: runs on a pull request with the contents of `.forgejo/workflows/tests.yaml` that is in `main`. This is the only pull request method supported because of how forgejo handles secrets differently from Github (secrets are not available in `pull_request` mode on forgejo) - `push`: run it on any commit pushes, and it duplicates the runs when run in a PR. `branches` should be set here to limit the execution, but I am not sure how it should be setup here. I left it without any `branches` also to debug on my side, but it should definitely be changed One thing I want to highlight as a consequence of this is that if you even need to update this, you will not see the live results of the changes in a PR. Best workflow to mitigate that is to also run on a well-defined branch name and use that as run through `on.push` flow.
siosm commented 2026-05-07 09:51:34 +00:00
Owner
Copy link

For now I think we'll only need to run CI on PRs.

For now I think we'll only need to run CI on PRs.
👍 1
siosm commented 2026-05-06 21:51:59 +00:00
Owner
Copy link

Can we run things as root in testing-farm jobs?

So something is off as we get permissions denied even though we are root:

+ [[ 0 -ne 0 ]]
+ rpm-ostree compose image --cachedir=cache --initialize --label=quay.expires-after=4w --max-layers=96 --force-nocache base-atomic.yaml base-atomic.ociarchive
bwrap: Creating new namespace failed: Operation not permitted
> Can we run things as root in testing-farm jobs? So something is off as we get permissions denied even though we are root: ``` + [[ 0 -ne 0 ]] + rpm-ostree compose image --cachedir=cache --initialize --label=quay.expires-after=4w --max-layers=96 --force-nocache base-atomic.yaml base-atomic.ociarchive bwrap: Creating new namespace failed: Operation not permitted ```
siosm commented 2026-05-06 22:10:54 +00:00
Owner
Copy link

So the experience is not great (the URL are not clickable in the action logs) so I'm doing basic checks using a runner in #759.

Let's focus on the more advanced compose checks here. Can you give me edit access to this PR so that I can iterate? Thanks

So the experience is not great (the URL are not clickable in the action logs) so I'm doing basic checks using a runner in https://forge.fedoraproject.org/atomic-desktops/config/pulls/759. Let's focus on the more advanced compose checks here. Can you give me edit access to this PR so that I can iterate? Thanks
lecris commented 2026-05-07 07:54:50 +00:00
Author
First-time contributor
Copy link

So the experience is not great (the URL are not clickable in the action logs)

Indeed I did not invest much time into that forgejo action mostly because I do not hope for it to be a long-term solution, and instead packit should take over that kind of interaction. I just want to offer it as a quick stop-gap solution to get other's CI back on their feet as fast as possible.

Let's focus on the more advanced compose checks here. Can you give me edit access to this PR so that I can iterate? Thanks

Oh I thought I already made it available. Try again, it should be available now.

A few tips on how to configure, you can add a provision step and specify more explicitly what configuration you need, e.g. to use a VM, add something like this to the plans.fmf:

provision:
  how: virtual

(available options I think are only virtual, container and artemis. See also hardware for some configuration like disk size)

Currently the default is to use a container (tmt-log gives you some basic data under it)

    provision
        queued provision.provision tasks
            #1: default-0
        
        provision.provision task #1: default-0
        how: container
        ansible: GuestAnsible(group=None, vars={})
        primary address: tmt-zf4-LQOXccBy
        topology address: tmt-zf4-LQOXccBy
        name: tmt-zf4-LQOXccBy
        multihost name: default-0
        arch: x86_64
        distro: Fedora Linux 44 (Container Image)
        kernel: 6.5.6-300.fc39.x86_64
        package manager: dnf5
        bootc builder: dnf5
        is container: yes
        is ostree: no
        is image mode: no
        is toolbox: no
        selinux: no
        systemd: no
        systemd soft-reboot: no
        rsync: no
        is superuser: yes
        can sudo: yes
        queued push tasks
            #1: push to default-0

but maybe that's the part that's getting in the way because it does not have systemd?

> So the experience is not great (the URL are not clickable in the action logs) Indeed I did not invest much time into that forgejo action mostly because I do not hope for it to be a long-term solution, and instead packit should take over that kind of interaction. I just want to offer it as a quick stop-gap solution to get other's CI back on their feet as fast as possible. > Let's focus on the more advanced compose checks here. Can you give me edit access to this PR so that I can iterate? Thanks Oh I thought I already made it available. Try again, it should be available now. A few tips on how to configure, you can add a [`provision` step](https://tmt.readthedocs.io/en/stable/plugins/provision.html) and specify more explicitly what configuration you need, e.g. to use a VM, add something like this to the `plans.fmf`: ``` provision: how: virtual ``` (available options I think are only `virtual`, `container` and `artemis`. See also `hardware` for some configuration like `disk` size) Currently the default is to use a container ([tmt-log](https://artifacts.dev.testing-farm.io/666e4289-5b2c-41f0-a31d-a50f48daf4b3/work-planseij8uzf4/tmt-run.log) gives you some basic data under it) ``` provision queued provision.provision tasks #1: default-0 provision.provision task #1: default-0 how: container ansible: GuestAnsible(group=None, vars={}) primary address: tmt-zf4-LQOXccBy topology address: tmt-zf4-LQOXccBy name: tmt-zf4-LQOXccBy multihost name: default-0 arch: x86_64 distro: Fedora Linux 44 (Container Image) kernel: 6.5.6-300.fc39.x86_64 package manager: dnf5 bootc builder: dnf5 is container: yes is ostree: no is image mode: no is toolbox: no selinux: no systemd: no systemd soft-reboot: no rsync: no is superuser: yes can sudo: yes queued push tasks #1: push to default-0 ``` but maybe that's the part that's getting in the way because it does not have systemd?
lecris commented 2026-05-07 08:21:20 +00:00
Author
First-time contributor
Copy link

So the experience is not great (the URL are not clickable in the action logs)

I did a quick check on what I can do to improve the experience, and it does not look good. It would require significant rewriting, making it a JS Github/Forgejo action or a compatibility layer at the cli. I would like to put off this work until there is clear long-term users of this tool over the alternatives that are in the works.

> So the experience is not great (the URL are not clickable in the action logs) I did a quick check on what I can do to improve the experience, and it does not look good. It would require significant rewriting, making it a JS Github/Forgejo action or a compatibility layer at the cli. I would like to put off this work until there is clear long-term users of this tool over the alternatives that are in the works.
👍 1
siosm force-pushed testing-farm from 309e2d8fe0 to 12bcfadd93
All checks were successful
Daily comps-sync check / validate (pull_request) Successful in 27s
Details
Validate manifests / validate (pull_request) Successful in 18s
Details
2026-05-07 10:29:56 +00:00 Compare
siosm commented 2026-05-07 10:47:01 +00:00
Owner
Copy link

Reading https://forgejo.org/docs/next/user/actions/reference/#onpull_request_target, pull_request_target is dangerous as it gives write access to the repo. It also uses the action from the main branch for good reasons, so we can not easily checks things in PRs here.

Reading https://forgejo.org/docs/next/user/actions/reference/#onpull_request_target, `pull_request_target` is dangerous as it gives write access to the repo. It also uses the action from the main branch for good reasons, so we can not easily checks things in PRs here.
siosm commented 2026-05-07 10:47:23 +00:00
Owner
Copy link

Ah, OK we need the push trigger

Ah, OK we need the push trigger
We do not use packages from this repo so disable it to speed up CI a
bit.
Trigger on push for testing
All checks were successful
Daily comps-sync check / validate (pull_request) Successful in 21s
Details
Validate manifests / validate (pull_request) Successful in 18s
Details
7816b3809d
wip
All checks were successful
Daily comps-sync check / validate (pull_request) Successful in 21s
Details
Validate manifests / validate (pull_request) Successful in 19s
Details
6cf61b28c1
lecris commented 2026-05-07 10:53:49 +00:00
Author
First-time contributor
Copy link

@siosm wrote in #757 (comment):

Reading https://forgejo.org/docs/next/user/actions/reference/#onpull_request_target, pull_request_target is dangerous as it gives write access to the repo.

Sorry, I don't quite see that part. The write permissions should not be there, but you can also just put permissions: {} to nullify them all. The only thing needed here are the secrets which is why it is pull_request_target not pull_request, and the metadata.

It also uses the action from the main branch for good reasons, so we can not easily checks things in PRs here.

Yes, that's the main difference between those 2, and also why tinkering with workflow file is difficult. The workflow file itself is quite minimal, so you can also just get that in early and try it out. Even with push trigger it would be tricky here because it will appear on my fork instead. Feel free to close the PR and reorganize it as needed to be able to test it.

@siosm wrote in https://forge.fedoraproject.org/atomic-desktops/config/pulls/757#issuecomment-698502: > Reading https://forgejo.org/docs/next/user/actions/reference/#onpull_request_target, `pull_request_target` is dangerous as it gives write access to the repo. Sorry, I don't quite see that part. The write permissions should not be there, but you can also just put `permissions: {}` to nullify them all. The only thing needed here are the secrets which is why it is `pull_request_target` not `pull_request`, and the metadata. > It also uses the action from the main branch for good reasons, so we can not easily checks things in PRs here. Yes, that's the main difference between those 2, and also why tinkering with workflow file is difficult. The workflow file itself is quite minimal, so you can also just get that in early and try it out. Even with push trigger it would be tricky here because it will appear on my fork instead. Feel free to close the PR and reorganize it as needed to be able to test it.
siosm commented 2026-05-07 10:55:43 +00:00
Owner
Copy link

Hum, I added the config to run under a VM but this is still running in a container:

    provision
        queued provision.provision tasks
            #1: default-0
        
        provision.provision task #1: default-0
        how: container
        ansible: GuestAnsible(group=None, vars={})
        primary address: tmt-3n8-BpmFdlnG
        topology address: tmt-3n8-BpmFdlnG
        name: tmt-3n8-BpmFdlnG
        multihost name: default-0
        arch: x86_64
        distro: Fedora Linux 44 (Container Image)
        kernel: 6.5.6-300.fc39.x86_64
        package manager: dnf5
        bootc builder: dnf5
        is container: yes
        is ostree: no
        is image mode: no
        is toolbox: no
        selinux: no
        systemd: no
        systemd soft-reboot: no
        rsync: no
        is superuser: yes
        can sudo: yes
        queued push tasks
            #1: push to default-0
        
        push task #1: push to default-0
    
        summary: 1 guest provisioned
Hum, I added the config to run under a VM but this is still running in a container: ``` provision queued provision.provision tasks #1: default-0 provision.provision task #1: default-0 how: container ansible: GuestAnsible(group=None, vars={}) primary address: tmt-3n8-BpmFdlnG topology address: tmt-3n8-BpmFdlnG name: tmt-3n8-BpmFdlnG multihost name: default-0 arch: x86_64 distro: Fedora Linux 44 (Container Image) kernel: 6.5.6-300.fc39.x86_64 package manager: dnf5 bootc builder: dnf5 is container: yes is ostree: no is image mode: no is toolbox: no selinux: no systemd: no systemd soft-reboot: no rsync: no is superuser: yes can sudo: yes queued push tasks #1: push to default-0 push task #1: push to default-0 summary: 1 guest provisioned ```
siosm commented 2026-05-07 11:00:23 +00:00
Owner
Copy link

Reading https://forgejo.org/docs/next/user/actions/reference/#onpull_request_target, pull_request_target is dangerous as it gives write access to the repo.

Sorry, I don't quite see that part. The write permissions should not be there, but you can also just put permissions: {} to nullify them all. The only thing needed here are the secrets which is why it is pull_request_target not pull_request, and the metadata.

I don't see a reference to permissions in https://forgejo.org/docs/next/user/actions/reference/. I know this exists on GitHub but is it implemented in Forgejo? But anyway, I think I understand the flow now and essentially this workflow should only run the code from the testing farm action so this should be reasonable.

It also uses the action from the main branch for good reasons, so we can not easily checks things in PRs here.

Yes, that's the main difference between those 2, and also why tinkering with workflow file is difficult. The workflow file itself is quite minimal, so you can also just get that in early and try it out. Even with push trigger it would be tricky here because it will appear on my fork instead. Feel free to close the PR and reorganize it as needed to be able to test it.

I added the push trigger for now so that we can use this one to try things out.

> > Reading https://forgejo.org/docs/next/user/actions/reference/#onpull_request_target, `pull_request_target` is dangerous as it gives write access to the repo. > > Sorry, I don't quite see that part. The write permissions should not be there, but you can also just put `permissions: {}` to nullify them all. The only thing needed here are the secrets which is why it is `pull_request_target` not `pull_request`, and the metadata. I don't see a reference to `permissions` in https://forgejo.org/docs/next/user/actions/reference/. I know this exists on GitHub but is it implemented in Forgejo? But anyway, I think I understand the flow now and essentially this workflow should only run the code from the testing farm action so this should be reasonable. > > It also uses the action from the main branch for good reasons, so we can not easily checks things in PRs here. > > Yes, that's the main difference between those 2, and also why tinkering with workflow file is difficult. The workflow file itself is quite minimal, so you can also just get that in early and try it out. Even with push trigger it would be tricky here because it will appear on my fork instead. Feel free to close the PR and reorganize it as needed to be able to test it. I added the push trigger for now so that we can use this one to try things out.
👍 1
lecris commented 2026-05-07 11:09:56 +00:00
Author
First-time contributor
Copy link

Hum, I added the config to run under a VM but this is still running in a container:

That is odd, I will check with testing-farm, why that is the case. In the meantime can try artemis (basically AWS/VM)

> Hum, I added the config to run under a VM but this is still running in a container: That is odd, I will check with testing-farm, why that is the case. In the meantime can try `artemis` (basically AWS/VM)
siosm force-pushed testing-farm from 6cf61b28c1
All checks were successful
Daily comps-sync check / validate (pull_request) Successful in 21s
Details
Validate manifests / validate (pull_request) Successful in 19s
Details
to ca45830a16
All checks were successful
Daily comps-sync check / validate (pull_request) Successful in 21s
Details
Validate manifests / validate (pull_request) Successful in 17s
Details
2026-05-07 16:51:33 +00:00 Compare
lecris commented 2026-05-11 13:10:59 +00:00
Author
First-time contributor
Copy link

I think I know what is going wrong here. This needs to use compose key. Trying to figure out how to expose that on the action

I think I know what is going wrong here. This needs to use `compose` key. Trying to figure out how to expose that on the action
[WIP] Try again with compose
All checks were successful
Daily comps-sync check / validate (pull_request) Successful in 22s
Details
Validate manifests / validate (pull_request) Successful in 18s
Details
1e17127c0f
lecris commented 2026-05-11 13:55:57 +00:00
Author
First-time contributor
Copy link

@siosm Huzzah we are getting somewhere https://artifacts.dev.testing-farm.io/56f59982-c346-4245-9a7f-f3e5d2b906ed/

@siosm Huzzah we are getting somewhere https://artifacts.dev.testing-farm.io/56f59982-c346-4245-9a7f-f3e5d2b906ed/
siosm commented 2026-05-11 21:02:05 +00:00
Owner
Copy link

This looks good!

This looks good!
siosm force-pushed testing-farm from 1e17127c0f
All checks were successful
Daily comps-sync check / validate (pull_request) Successful in 22s
Details
Validate manifests / validate (pull_request) Successful in 18s
Details
to 47c72eb650
All checks were successful
Daily comps-sync check / validate (pull_request) Successful in 22s
Details
Validate manifests / validate (pull_request) Successful in 18s
Details
2026-05-11 21:05:40 +00:00 Compare
siosm commented 2026-05-12 07:17:08 +00:00
Owner
Copy link
Maximum test time '5m' exceeded.
Adjust the test 'duration' attribute if necessary.
https://tmt.readthedocs.io/en/stable/spec/tests.html#duration

😅 We'll need more than that 🙂

``` Maximum test time '5m' exceeded. Adjust the test 'duration' attribute if necessary. https://tmt.readthedocs.io/en/stable/spec/tests.html#duration ``` 😅 We'll need more than that 🙂
ci/tests.fmf: Add duration
All checks were successful
Daily comps-sync check / validate (pull_request) Successful in 27s
Details
Validate manifests / validate (pull_request) Successful in 18s
Details
e65ad52b5a
siosm commented 2026-05-12 09:42:39 +00:00
Owner
Copy link

This worked! https://forge.fedoraproject.org/ci/_atomic-desktops-config/actions/runs/10/jobs/0/attempt/1

Looks like it took ~18 min: https://artifacts.dev.testing-farm.io/65d63f3b-a0a4-43ce-bd64-dc1a21d93b1b/

This worked! https://forge.fedoraproject.org/ci/_atomic-desktops-config/actions/runs/10/jobs/0/attempt/1 Looks like it took ~18 min: https://artifacts.dev.testing-farm.io/65d63f3b-a0a4-43ce-bd64-dc1a21d93b1b/
🎉 1
siosm commented 2026-05-20 14:31:23 +00:00
Owner
Copy link

Can we run multiple jobs in parallel? I think we would need multiple workflows? (so we would really need: forge/forge#568)

Looking at https://forge.fedoraproject.org/ci/testing-farm, I see: plan .* Regex pattern of plans to be run

Can we run multiple jobs in parallel? I think we would need multiple workflows? (so we would really need: https://forge.fedoraproject.org/forge/forge/issues/568) Looking at https://forge.fedoraproject.org/ci/testing-farm, I see: `plan .* Regex pattern of plans to be run`
lecris commented 2026-05-20 14:36:42 +00:00
Author
First-time contributor
Copy link

@siosm wrote in #757 (comment):

Can we run multiple jobs in parallel? I think we would need multiple workflows? (so we would really need: forge/forge#568)

Looking at https://forge.fedoraproject.org/ci/testing-farm, I see: plan .* Regex pattern of plans to be run

Multiple plans, yes, that will be consolidated into one testing-farm job and result, but the individual plan result would be seen on the testing-farm results.

Multiple testing-farm queries, that is blocked part by forge/forge#568 I believe. I tried that on https://forge.fedoraproject.org/ci/_fedora-kiwi-descriptions/actions/runs/1/jobs/0/attempt/1 and they were stuck waiting on a forgejo runner to be available.

But if you can live without the separation of results in forgejo for a while, and waiting on the forgejo runner to be available in general, then you should not really be blocked right now

@siosm wrote in https://forge.fedoraproject.org/atomic-desktops/config/pulls/757#issuecomment-713803: > Can we run multiple jobs in parallel? I think we would need multiple workflows? (so we would really need: forge/forge#568) > > Looking at https://forge.fedoraproject.org/ci/testing-farm, I see: `plan .* Regex pattern of plans to be run` Multiple plans, yes, that will be consolidated into one testing-farm job and result, but the individual plan result would be seen on the testing-farm results. Multiple testing-farm queries, that is blocked part by forge/forge#568 I believe. I tried that on https://forge.fedoraproject.org/ci/_fedora-kiwi-descriptions/actions/runs/1/jobs/0/attempt/1 and they were stuck waiting on a forgejo runner to be available. But if you can live without the separation of results in forgejo for a while, and waiting on the forgejo runner to be available in general, then you should not really be blocked right now
Add a test that composes Silverblue
All checks were successful
Daily comps-sync check / validate (pull_request) Successful in 28s
Details
Validate manifests / validate (pull_request) Successful in 20s
Details
ef096fb767
lecris commented 2026-05-21 10:33:07 +00:00
Author
First-time contributor
Copy link

Oops I made the testing-farm token too short-lived. I've re-triggered it https://artifacts.dev.testing-farm.io/a1a3805e-3509-4f61-b354-19c831d9f9dc/

Oops I made the testing-farm token too short-lived. I've re-triggered it https://artifacts.dev.testing-farm.io/a1a3805e-3509-4f61-b354-19c831d9f9dc/
siosm commented 2026-05-21 16:30:19 +00:00
Owner
Copy link

Thanks, it looks like this is working.

Thanks, it looks like this is working.
Split tests to run in parallel
Some checks are pending
Daily comps-sync check / validate (pull_request) Waiting to run
Details
Validate manifests / validate (pull_request) Waiting to run
Details
91c34aebab
Actually run tests in parallel :)
Some checks failed
Daily comps-sync check / validate (pull_request) Has been cancelled
Details
Validate manifests / validate (pull_request) Has been cancelled
Details
464ffcbd70
lecris commented 2026-05-21 17:02:29 +00:00
Author
First-time contributor
Copy link

Saw your intent :). You need different plans (each with a single test) in order to have these run in parallel, hopefully the example here clarifies how things need to be organized to run in a specific way

Saw your intent :). You need different plans (each with a single test) in order to have these run in parallel, hopefully the example here clarifies how things need to be organized to run in a specific way
Try running on docker-slim
Some checks failed
Daily comps-sync check / validate (pull_request) Has been cancelled
Details
Validate manifests / validate (pull_request) Has been cancelled
Details
b10f840ee4
Fix concurrency
Some checks failed
Daily comps-sync check / validate (pull_request) Has been cancelled
Details
Validate manifests / validate (pull_request) Has been cancelled
Details
26c017c2b3
siosm commented 2026-05-21 20:56:22 +00:00
Owner
Copy link

Ah, thanks!

Ah, thanks!
Cleanup test jobs
Some checks are pending
Daily comps-sync check / validate (pull_request) Waiting to run
Details
Validate manifests / validate (pull_request) Waiting to run
Details
be690ebae5
Cleanup test jobs bis
Some checks are pending
Daily comps-sync check / validate (pull_request) Waiting to run
Details
Validate manifests / validate (pull_request) Waiting to run
Details
deda6fafbf
Try Fedora 44
All checks were successful
Daily comps-sync check / validate (pull_request) Successful in 28s
Details
Validate manifests / validate (pull_request) Successful in 19s
Details
0f2eeb2af7
lecris reviewed 2026-05-21 21:35:38 +00:00
.forgejo/workflows/tests.yml
@ -0,0 +24,4 @@
with:
api_key: ${{ secrets.TESTING_FARM_API_TOKEN }}
# compose: "Fedora-Rawhide"
compose: "Fedora-44"
lecris commented 2026-05-21 21:35:38 +00:00
Author
First-time contributor
Copy link

List of composes is here. Can take Fedora-latest

List of composes is [here](https://api.testing-farm.io/v0.2/composes/public). Can take `Fedora-latest`
👍 1
siosm commented 2026-05-27 22:29:00 +00:00
Owner
Copy link

Thanks for helping me figure this out. I think we'll move forward with that. I've cleaned things up and made: #767

Thanks for helping me figure this out. I think we'll move forward with that. I've cleaned things up and made: https://forge.fedoraproject.org/atomic-desktops/config/pulls/767
lecris commented 2026-05-28 08:34:49 +00:00
Author
First-time contributor
Copy link

@siosm wrote in #757 (comment):

Thanks for helping me figure this out. I think we'll move forward with that. I've cleaned things up and made: #767

Awesome. I guess I can clean up the fork also?

@siosm wrote in https://forge.fedoraproject.org/atomic-desktops/config/pulls/757#issuecomment-760676: > Thanks for helping me figure this out. I think we'll move forward with that. I've cleaned things up and made: #767 Awesome. I guess I can clean up the fork also?
lecris closed this pull request 2026-05-28 08:34:49 +00:00
siosm commented 2026-05-28 15:49:47 +00:00
Owner
Copy link

Yes, we should be able to cleanup the fork now.

Yes, we should be able to cleanup the fork now.
siosm referenced this pull request from a commit 2026-06-01 21:55:10 +00:00
Migrate Zuul CI to tmt definition
siosm referenced this pull request from a commit 2026-06-01 22:06:34 +00:00
Migrate Zuul CI to tmt definition
siosm referenced this pull request from a commit 2026-06-01 22:09:16 +00:00
Migrate Zuul CI to tmt definition
All checks were successful
Daily comps-sync check / validate (pull_request) Successful in 28s
Details
Validate manifests / validate (pull_request) Successful in 19s
Details

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
Closed As
Duplicate
 Closed with the reason of Duplicate

  
Closed As
Fixed
 Closed with the reason of Fixed

  
Closed As
Insufficient data
 Closed with the reason of Insufficient data

  
Closed As
Invalid
 Closed with the reason of Invalid

  
gateit
Use by Zuul CI

No labels
Closed As
Duplicate
Closed As
Fixed
Closed As
Insufficient data
Closed As
Invalid
gateit
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
atomic-desktops/config!757
No description provided.