Query both .gitea and .github for workflows #13187

New Issue

GiteaMirror · 2025-11-02T10:34:09-06:00

GiteaMirror commented

2025-11-02 10:34:09 -06:00

Originally created by @Sharaf5 on GitHub (Jun 21, 2024).

Description

I had some already set workflows inside «.github» dir
Once I created one inside «.gitea» I no longer see first ones

Gitea Version

1.22

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

dockerized

How are you running Gitea?

inside docker «gitea:latest» and «act_runner:latest»

Database

SQLite

Originally created by @Sharaf5 on GitHub (Jun 21, 2024). ### Description I had some already set workflows inside «.github» dir Once I created one inside «.gitea» I no longer see first ones ### Gitea Version 1.22 ### Can you reproduce the bug on the Gitea demo site? Yes ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version _No response_ ### Operating System dockerized ### How are you running Gitea? inside docker «gitea:latest» and «act_runner:latest» ### Database SQLite

GiteaMirror added the topic/gitea-actions type/proposal issue/needs-feedback labels 2025-11-02 10:34:09 -06:00

GiteaMirror closed this issue

2025-11-02 10:34:09 -06:00

GiteaMirror commented

2025-11-02 10:34:10 -06:00

@delvh commented on GitHub (Jun 21, 2024):

That isn't exactly a bug but rather intended behavior:
Gitea/Act first queries the .gitea folder for workflows.
If it doesn't find any, it checks if the repo is perhaps coming from GitHub, so if there is a .github folder that we fallback to.
It is not intended that you have both, as a repo should be hosted either mainly on Gitea, or mainly on GitHub.
Not both.

I don't see a usecase for querying both, it complicates a lot of calculations for no real benefit.

@delvh commented on GitHub (Jun 21, 2024): That isn't exactly a bug but rather intended behavior: Gitea/Act first queries the `.gitea` folder for workflows. If it doesn't find any, it checks if the repo is perhaps coming from GitHub, so if there is a `.github` folder that we fallback to. It is not intended that you have both, as a repo should be hosted either mainly on Gitea, or mainly on GitHub. Not both. I don't see a usecase for querying both, it complicates a lot of calculations for no real benefit.

GiteaMirror commented

2025-11-02 10:34:10 -06:00

@Sharaf5 commented on GitHub (Jun 21, 2024):

I really don't find it useful to have a hard coded folders and only parse one
this should be a list of folders in repe settings where it's parsed one by one and all executions are returned with defauld to both gitea and github

@Sharaf5 commented on GitHub (Jun 21, 2024): I really don't find it useful to have a hard coded folders and only parse one this should be a list of folders in repe settings where it's parsed one by one and all executions are returned with defauld to both gitea and github

GiteaMirror commented

2025-11-02 10:34:10 -06:00

@delvh commented on GitHub (Jun 21, 2024):

Why is it "not useful to have hard coded folders"?
What's the benefit of querying both?
Why not store all files in the same directory?

@delvh commented on GitHub (Jun 21, 2024): Why is it "not useful to have hard coded folders"? What's the benefit of querying both? Why not store all files in the same directory?

GiteaMirror commented

2025-11-02 10:34:11 -06:00

@Sharaf5 commented on GitHub (Jun 21, 2024):

I was willing build a repo with all my reusable workflow with some of theme to run on github and not others and some for gitea and github
there might be someone else who want to use another folder name like ci or workflows for workflows

@Sharaf5 commented on GitHub (Jun 21, 2024): I was willing build a repo with all my reusable workflow with some of theme to run on github and not others and some for gitea and github there might be someone else who want to use another folder name like `ci` or `workflows` for workflows

GiteaMirror commented

2025-11-02 10:34:11 -06:00

@lunny commented on GitHub (Jun 22, 2024):

A proposal label is suitable for this issue.

@lunny commented on GitHub (Jun 22, 2024): A `proposal` label is suitable for this issue.

GiteaMirror commented

2025-11-02 10:34:11 -06:00

@Sharaf5 commented on GitHub (Jun 22, 2024):

Yes @lunny but I think Actions shouldn't use one dir is still a suitable title
anyway, any intension to implement it ?

@Sharaf5 commented on GitHub (Jun 22, 2024): Yes @lunny but I think `Actions shouldn't use one dir` is still a suitable title anyway, any intension to implement it ?

GiteaMirror commented

2025-11-02 10:34:11 -06:00

@yp05327 commented on GitHub (Jun 24, 2024):

I think this is a good proposal.
As there are still some unsupported workflows syntax in Gitea Action now (and in future), users can not completely using the same workflows in both GitHub and Gitea in some cases. So users can disable and rewrite them in .gitea/workflows and will not effect the existing workflows for using in GitHub.

@yp05327 commented on GitHub (Jun 24, 2024): I think this is a good proposal. As there are still some unsupported workflows syntax in Gitea Action now (and in future), users can not completely using the same workflows in both GitHub and Gitea in some cases. So users can disable and rewrite them in `.gitea/workflows` and will not effect the existing workflows for using in GitHub.

GiteaMirror commented

2025-11-02 10:34:11 -06:00

@lunny commented on GitHub (Jun 24, 2024):

I think this is a good proposal. As there are still some unsupported workflows syntax in Gitea Action now (and in future), users can not completely using the same workflows in both GitHub and Gitea in some cases. So users can disable and rewrite them in .gitea/workflows and will not effect the existing workflows for using in GitHub.

You requirement looks like different from the proposal one. You need an override feature. Maybe .gitea/workflows/test.yaml will override .github/workflows/test.yaml? It will become more complicated.

@lunny commented on GitHub (Jun 24, 2024): > I think this is a good proposal. As there are still some unsupported workflows syntax in Gitea Action now (and in future), users can not completely using the same workflows in both GitHub and Gitea in some cases. So users can disable and rewrite them in `.gitea/workflows` and will not effect the existing workflows for using in GitHub. You requirement looks like different from the proposal one. You need an override feature. Maybe `.gitea/workflows/test.yaml` will override `.github/workflows/test.yaml`? It will become more complicated.

GiteaMirror commented

2025-11-02 10:34:12 -06:00

@yp05327 commented on GitHub (Jun 24, 2024):

override is more complex and limit the usage.

@yp05327 commented on GitHub (Jun 24, 2024): override is more complex and limit the usage.

GiteaMirror commented

2025-11-02 10:34:12 -06:00

@wxiaoguang commented on GitHub (Jun 24, 2024):

I was willing build a repo with all my reusable workflow with some of theme to run on github and not others and some for gitea and github

Maybe you could try:

use symlink (haven't tested whether it really works for actions, but it is a proper approach)
use a bot to sync some "workflows"

As the discussion above, making ".gitea" actions inherit/re-use the ".github" actions is not a good approach, it would only cause bugs and confusions.

@wxiaoguang commented on GitHub (Jun 24, 2024): > I was willing build a repo with all my reusable workflow with some of theme to run on github and not others and some for gitea and github Maybe you could try: 1. use symlink (haven't tested whether it really works for actions, but it is a proper approach) 2. use a bot to sync some "workflows" ---- As the discussion above, making ".gitea" actions inherit/re-use the ".github" actions is not a good approach, it would only cause bugs and confusions.

GiteaMirror commented

2025-11-02 10:34:12 -06:00

@Sharaf5 commented on GitHub (Jun 24, 2024):

I think this is a good proposal. As there are still some unsupported workflows syntax in Gitea Action now (and in future), users can not completely using the same workflows in both GitHub and Gitea in some cases. So users can disable and rewrite them in .gitea/workflows and will not effect the existing workflows for using in GitHub.

Do you meen rewriting the workflow manually or overwritting on gitea
Manual rewriting by user will be going with my proposal but the overriding dirs or files would just add more complecation for code even if there is a copy of the file in two dirs as one could disable the workflow

@Sharaf5 commented on GitHub (Jun 24, 2024): > I think this is a good proposal. As there are still some unsupported workflows syntax in Gitea Action now (and in future), users can not completely using the same workflows in both GitHub and Gitea in some cases. So users can disable and rewrite them in `.gitea/workflows` and will not effect the existing workflows for using in GitHub. Do you meen rewriting the workflow manually or overwritting on gitea Manual rewriting by user will be going with my proposal but the overriding dirs or files would just add more complecation for code even if there is a copy of the file in two dirs as one could disable the workflow

GiteaMirror commented

2025-11-02 10:34:12 -06:00

@Sharaf5 commented on GitHub (Jun 24, 2024):

use symlink (haven't tested whether it really works for actions, but it is a proper approach)

Don't seem to be best thing but I may try

use a bot to sync some "workflows"

Don't understand this

@Sharaf5 commented on GitHub (Jun 24, 2024): > 1. use symlink (haven't tested whether it really works for actions, but it is a proper approach) Don't seem to be best thing but I may try > 2. use a bot to sync some "workflows" Don't understand this

GiteaMirror commented

2025-11-02 10:34:12 -06:00

@Sharaf5 commented on GitHub (Jun 24, 2024):

As the discussion above, making ".gitea" actions inherit/re-use the ".github" actions is not a good approach, it would only cause bugs and confusions.

it's really built on top of act
so, why I should repeat file that has a working workflow compatible with both, we need only to disable and rewrite manually what makes conflection

and it's the biggest deal for act_runner to still compatible with github action workflow syntax for now as gitea action still lake many of it's features

also gitea is a self hosted and one may bring it down for any reason ... more compitability between sites meens mirrors could run actions easly once one has any downtime on servers

what I was thinking about is

if we have a setting option in the repo that has dirs in sequance to load workfloaws from
dirs are scaned one by one
workflows are listed by reead sequance, appears in the ui by it's name properity or file name combined with a badge of the dir it comes from or the number of that dir in the squence

then like normal

all workflows are send to validation
valid workflows sent to runners

that would help mixid workflows and mirrord setup like most of mine

I really tried to implement it myself as a new learning task but seams go is not easy for me at all

@Sharaf5 commented on GitHub (Jun 24, 2024): > As the discussion above, making ".gitea" actions inherit/re-use the ".github" actions is not a good approach, it would only cause bugs and confusions. it's really built on top of act so, why I should repeat file that has a working workflow compatible with both, we need only to disable and rewrite manually what makes conflection and it's the biggest deal for act_runner to still compatible with github action workflow syntax for now as gitea action still lake many of it's features also gitea is a self hosted and one may bring it down for any reason ... more compitability between sites meens mirrors could run actions easly once one has any downtime on servers what I was thinking about is - if we have a setting option in the repo that has dirs in sequance to load workfloaws from - dirs are scaned one by one - workflows are listed by reead sequance, appears in the ui by it's name properity or file name combined with a badge of the dir it comes from or the number of that dir in the squence then like normal - all workflows are send to validation - valid workflows sent to runners that would help mixid workflows and mirrord setup like most of mine I really tried to implement it myself as a new learning task but seams go is not easy for me at all

GiteaMirror commented

2025-11-02 10:34:13 -06:00

@Sharaf5 commented on GitHub (Jun 24, 2024):

I also wondered

what if act_runner developed to support many workflow syntax and integrated with more tools like drone or othe ci tools would it just run from one dir
only working from a limited dir means I would prefer the one compatible with more tools rather than the brand name dir

I may be overthinking but why not

@Sharaf5 commented on GitHub (Jun 24, 2024): I also wondered - what if act_runner developed to support many workflow syntax and integrated with more tools like drone or othe ci tools would it just run from one dir - only working from a limited dir means I would prefer the one compatible with more tools rather than the brand name dir I may be overthinking but why not

GiteaMirror commented

2025-11-02 10:34:13 -06:00

@GiteaBot commented on GitHub (Jul 25, 2024):

We close issues that need feedback from the author if there were no new comments for a month. 🍵

@GiteaBot commented on GitHub (Jul 25, 2024): We close issues that need feedback from the author if there were no new comments for a month. :tea:

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#13187

Query both .gitea and .github for workflows #13187

Description

Gitea Version

Can you reproduce the bug on the Gitea demo site?

Log Gist

Screenshots

Git Version

Operating System

How are you running Gitea?

Database

Query both `.gitea` and `.github` for workflows #13187