feature request: workflow calls should allow omitting the `runs-on` item

aviallon commented

2025-09-04 22:51:55 +00:00

           "runs-on": {
             "type": "runs-on",
             "required": true
           },

GitHub Actions, for instance, forbids the presence of this item. Making it required increases porting effort (and confusion for my part).

Related comments:

https://code.forgejo.org/forgejo/runner/src/commit/69c6c70845d44ff833fa1c8efa4e1701239aca91/act/schema/workflow_schema.json#L1475-L1478 GitHub Actions, for instance, **forbids** the presence of this item. Making it required increases porting effort (and confusion for my part). Related comments: - https://codeberg.org/forgejo/forgejo/issues/7828#issuecomment-6845476 - https://codeberg.org/forgejo/forgejo/issues/7828#issuecomment-6845737

👍 1

earl-warren added the

Status

Need More Info

label

2025-09-08 07:08:38 +00:00

earl-warren commented

2025-09-08 07:14:15 +00:00

Contributor

The problem with not having a runs-on explicitly set is that there really is no way to figure out what the appropriate value is in the case of a migration.

the GitHub environment provides a default that is not supported by Forgejo (a large pre-populated virtual machine)
this default change over time
the execution environment of reach runner uses labels that need to be learned when porting from GitHub because there is no convention for choosing the one that is will provide something closes to the GitHub default

In other words, I do not see a solution that would make things less confusing. Or maybe with a better documentation.

Any ideas?

The problem with not having a `runs-on` explicitly set is that there really is no way to figure out what the appropriate value is in the case of a migration. - the GitHub environment provides a default that is not supported by Forgejo (a large pre-populated virtual machine) - this default change over time - the execution environment of reach runner uses labels that need to be learned when porting from GitHub because there is no convention for choosing the one that is will provide something closes to the GitHub default In other words, I do not see a solution that would make things less confusing. Or maybe with a better documentation. Any ideas?

aviallon commented

2025-09-08 07:41:34 +00:00

Author

Perhaps setting the default runner in the forgejo-runner's config would make sense?

earl-warren commented

2025-09-08 08:40:36 +00:00

Contributor

Maybe. But I'm struggling to imagine what such a default might be so that it avoids any confusion. To every user. 🤔

aviallon commented

2025-11-05 01:14:36 +00:00

Author

@earl-warren I understand your point.
I seriously believe the only option is to force the user to configure it, or have the Forgejo server give us a default value for all runners.
In my case, I have a default set of runner with a the tag 'docker', which is what I'd like to use for workflow calls.

WAIT.
The problem might be different still: we already specify the runs-on in the callee. Why would we need to set it in the caller too? How are conflicting values handled?

@earl-warren I understand your point. I seriously believe the only option is to force the user to configure it, or have the Forgejo server give us a default value for all runners. In my case, I have a default set of runner with a the tag 'docker', which is what I'd like to use for workflow calls. WAIT. The problem might be different still: we **already** specify the `runs-on` in the **callee**. Why would we need to set it in the **caller** too? How are conflicting values handled?

2franix commented

2025-11-05 08:43:29 +00:00

Contributor

The problem might be different still: we already specify the runs-on in the callee. Why would we need to set it in the caller too?

Exactly. That was my point in #7828. And that's why I'm so confused that it got closed 😞 The callee should run on the same runner as the caller, always.

there really is no way to figure out what the appropriate value is in the case of a migration

Not sure what "a migration" is in this context.

> The problem might be different still: we already specify the runs-on in the callee. Why would we need to set it in the caller too? Exactly. That was my point in [#7828](https://codeberg.org/forgejo/forgejo/issues/7828). And that's why I'm so confused that it got closed 😞 The callee should run on the same runner as the caller, always. > there really is no way to figure out what the appropriate value is in the case of a migration Not sure what "a migration" is in this context.

earl-warren commented

2025-11-05 11:30:41 +00:00

Contributor

@2franix "a migration" is meant as "when migrating a workflow from GitHub Actions to Forgejo Actions"

👍 1

earl-warren commented

2025-11-05 11:37:01 +00:00

Contributor

@aviallon wrote in #937 (comment):

The problem might be different still: we already specify the runs-on in the callee. Why would we need to set it in the caller too? How are conflicting values handled?

The "runs-on" of a workflow is evaluated by Forgejo which is not aware of the caller callee relationship that is interpreted and acted upon by the runner.

Note that a given workflow can be called from another workflow (in which case it will be run according to the runs-on of the caller) or it can be run standalone using the specified runs-on.

If the runs-on of the caller and the callee are different, the runs-on of the caller will be used. If they are not compatible, breakage will happen.

@aviallon wrote in https://code.forgejo.org/forgejo/runner/issues/937#issuecomment-65078: > The problem might be different still: we **already** specify the `runs-on` in the **callee**. Why would we need to set it in the **caller** too? How are conflicting values handled? The "runs-on" of a workflow is evaluated by Forgejo which is not aware of the caller callee relationship that is interpreted and acted upon by the runner. Note that a given workflow can be called from another workflow (in which case it will be run according to the runs-on of the caller) or it can be run standalone using the specified runs-on. If the runs-on of the caller and the callee are different, the runs-on of the caller will be used. If they are not compatible, breakage will happen.

earl-warren commented

2025-11-05 11:39:36 +00:00

Contributor

I seriously believe the only option is to force the user to configure it, or have the Forgejo server give us a default value for all runners.
In my case, I have a default set of runner with a the tag 'docker', which is what I'd like to use for workflow calls.

Although I don't quite see the benefit or the implementation details, I don't need to. It should be discussed based on merits and concrete use cases in the context of a new feature request. Could you please open one?

> I seriously believe the only option is to force the user to configure it, or have the Forgejo server give us a default value for all runners. In my case, I have a default set of runner with a the tag 'docker', which is what I'd like to use for workflow calls. Although I don't quite see the benefit or the implementation details, I don't need to. It should be discussed based on merits and concrete use cases in the context of [a new feature request](https://code.forgejo.org/forgejo/forgejo-actions-feature-requests/issues/new?template=.forgejo%2fissue_template%2ffeature-request.yaml). Could you please open one?

2franix commented

2025-11-05 13:02:55 +00:00

Contributor

The "runs-on" of a workflow is evaluated by Forgejo which is not aware of the caller callee relationship that is interpreted and acted upon by the runner.

Note that a given workflow can be called from another workflow (in which case it will be run according to
If the runs-on of the caller and the callee are different, the runs-on of the caller will be used. If they are not compatible, breakage will happen.

So it looks to me that the runs-on should not be mandatory when workflows only have a workflow_call trigger, but no trigger such as pull_request or push that would make it run standalone.

That was the problem I described in #7828. From what you explained, I added dummy runs-on properties in workflows to make them pass the new validation checks but those are meaningless in my use case. Isn't there a possibility to make runs-on optional, then ?

> The "runs-on" of a workflow is evaluated by Forgejo which is not aware of the caller callee relationship that is interpreted and acted upon by the runner. > > Note that a given workflow can be called from another workflow (in which case it will be run according to > If the runs-on of the caller and the callee are different, the runs-on of the caller will be used. If they are not compatible, breakage will happen. So it looks to me that the runs-on should not be mandatory when workflows only have a `workflow_call` trigger, but no trigger such as `pull_request` or `push` that would make it run standalone. That was the problem I described in [#7828](https://codeberg.org/forgejo/forgejo/issues/7828). From what you explained, I added dummy runs-on properties in workflows to make them pass the new validation checks but those are meaningless in my use case. Isn't there a possibility to make runs-on optional, then ?

👍 1

earl-warren commented

2025-11-05 13:31:00 +00:00

Contributor

I agree that in this particular case it would make sense to have them optional and to document that. Whether or not it is worth having is best discussed in a feature request. Unless you think this should be considered a bug?

2franix commented

2025-11-05 15:22:08 +00:00

Contributor

To me this is clearly a bug, as it is merely a matter of false positive when checking the workflow's validity. It does run successfully without runs-on if we bypass the check.

But I'm fine either way, as long it goes in the direction of fixing it 🙂

And thank you for the discussion and all the work with forgejo. I don't want my complaint to sound like I'm not grateful for the dedication of people like you towards the community! ❤️

To me this is clearly a bug, as it is merely a matter of false positive when checking the workflow's validity. It does run successfully without runs-on if we bypass the check. But I'm fine either way, as long it goes in the direction of fixing it 🙂 And thank you for the discussion and all the work with forgejo. I don't want my complaint to sound like I'm not grateful for the dedication of people like you towards the community! ❤️

👍 1 ❤️ 1

aviallon commented

2025-11-05 16:44:37 +00:00

Author

@earl-warren what @2franix says is exactly my point, and also my use-case. When patching the runner to make runs-on optional in the particular situation I am in (which might or might not be common), it works perfectly, and has the added bonus of being compatible with Github's syntax.

earl-warren commented

2025-11-06 08:44:19 +00:00

Contributor

It does run successfully without runs-on if we bypass the check.
When patching the runner to make runs-on optional in the particular situation I am in (which might or might not be common), it works perfectly

In your use case, it does. But not in all cases. When the check is enforced, it works in all cases, including yours as long as you add the runs-on.

I can understand you perceive the static check as being too picky and advocate for a change to relax its requirements in your specific use cases. But I disagree that it is a bug because the runner works as intended.

> It does run successfully without runs-on if we bypass the check. > When patching the runner to make runs-on optional in the particular situation I am in (which might or might not be common), it works perfectly In your use case, it does. But not in all cases. When the check is enforced, it works in all cases, including yours as long as you add the runs-on. I can understand you perceive the static check as being too picky and advocate for a change to relax its requirements in your specific use cases. But I disagree that it is a bug because the runner works as intended.

aviallon commented

2025-11-12 11:55:04 +00:00

Author

@earl-warren if it is not a bug, perhaps it should be rephrased as a feature request then?

aviallon changed title from ~~bug: workflow-job should not have a runs-on item~~ to feature request: workflow calls should allow omitting the runs-on item

2025-11-12 11:55:45 +00:00

mfenniak commented

2025-12-16 18:11:45 +00:00

Owner

This issue is on my short list of open issues which are expected to be fixed by https://codeberg.org/forgejo/forgejo/pulls/10448.

❤️ 2

mfenniak commented

2026-01-02 03:13:48 +00:00

Owner

With the completion of all the work listed in this comment, it's now possible to omit runs-on and have it be defined by the jobs within the reusable workflow. Closing this issue. 🎉

With the completion of all the work listed in [this comment](https://codeberg.org/forgejo/forgejo/issues/9768#issuecomment-8828016), it's now possible to omit `runs-on` and have it be defined by the jobs within the reusable workflow. Closing this issue. 🎉

🚀 1

mfenniak closed this issue

2026-01-02 03:13:48 +00:00

Rows
Columns

feature request: workflow calls should allow omitting the runs-on item #937

feature request: workflow calls should allow omitting the `runs-on` item #937