[Actions] Globally resolvable action names #10869

@delvh commented on GitHub (May 18, 2023):

No.
Give me a reason for reopening.

@delvh commented on GitHub (May 18, 2023): No. Give me a reason for reopening.

GiteaMirror commented

@delvh commented on GitHub (May 18, 2023):

That is not a good idea.

@delvh commented on GitHub (May 18, 2023): That is not a good idea.

GiteaMirror commented

@delvh commented on GitHub (May 18, 2023):

I actually wish that DEFAULT_ACTIONS_URL (app.ini) is an array instead of a string.
With default value APP_URL (host your own actions via relative syntax), (https://gitea.com,
The last time I checked it was a place with mostly outdated copies of github),https://github.com

okay, I can understand that.
Should we reopen this issue as that, or open a separate issue for it?

@delvh commented on GitHub (May 18, 2023): > I actually wish that DEFAULT_ACTIONS_URL (app.ini) is an array instead of a string. With default value APP_URL (host your own actions via relative syntax), (https://gitea.com, The last time I checked it was a place with mostly outdated copies of github),https://github.com okay, I can understand that. Should we reopen this issue as that, or open a separate issue for it?

GiteaMirror commented

@ChristopherHX commented on GitHub (May 18, 2023):

Should we reopen this issue as that, or open a separate issue for it?

Seems like I misunderstood the intention of this issue, my proposal should be a separate issue then.

However in both scenarios is actions/setup-python@v4 resolveable by default. So I thought that might be related.

@ChristopherHX commented on GitHub (May 18, 2023): > Should we reopen this issue as that, or open a separate issue for it? Seems like I misunderstood the intention of this issue, my proposal should be a separate issue then. However in both scenarios is `actions/setup-python@v4` resolveable by default. So I thought that might be related.

GiteaMirror commented

@silverwind commented on GitHub (May 18, 2023):

Looking closer at podman, it actually has a config that seems to default to:

unqualified-search-registries = ["docker.io", "quay.io"]

From that, I take it could be possible to define multiple search prefixes and I would suggest a default of ["https://github.com"], with those URLs checked in sequence. I would not recommend adding the current instance at the end by default, as it would break global resolution if the value is anything but the single Github URL.

@silverwind commented on GitHub (May 18, 2023): Looking closer at podman, it actually has a config that seems to default to: ``` unqualified-search-registries = ["docker.io", "quay.io"] ``` From that, I take it could be possible to define multiple search prefixes and I would suggest a default of `["https://github.com"]`, with those URLs checked in sequence. I would not recommend adding the current instance at the end by default, as it would break global resolution if the value is anything but the single Github URL.

GiteaMirror commented

@ChristopherHX commented on GitHub (May 18, 2023):

It will resolve to instance-specific URL https://gitea.com/actions/setup-python which I see very problematic because it makes action names ambigous across multiple gitea instances and github itself (where this will work).

The default is hardcoded to https://gitea.com, it is only the instance-specific url if Gitea Actions is hosted on https://gitea.com. For myself it is still https://gitea.com even if the instance is *.home

@ChristopherHX commented on GitHub (May 18, 2023): > It will resolve to instance-specific URL https://gitea.com/actions/setup-python which I see very problematic because it makes action names ambigous across multiple gitea instances and github itself (where this will work). The default is hardcoded to `https://gitea.com`, it is only the instance-specific url if Gitea Actions is hosted on https://gitea.com. For myself it is still https://gitea.com even if the instance is *.home

GiteaMirror commented

@silverwind commented on GitHub (May 18, 2023):

Yeah, I understand that it's set gitea.com on all instances. That's better than current instance, but still not globally resolvable.

I would set to github.com in all my instances and I would strongly suggest the default to be adjusted to that. GitHub Actions does not support this prefix syntax, so the only way for workflows to be portable in the github -> gitea direction is with the proposed default.

@silverwind commented on GitHub (May 18, 2023): Yeah, I understand that it's set `gitea.com` on all instances. That's better than current instance, but still not globally resolvable. I would set to `github.com` in all my instances and I would strongly suggest the default to be adjusted to that. GitHub Actions [does not](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsuses) support this prefix syntax, so the only way for workflows to be portable in the github -> gitea direction is with the proposed default.

GiteaMirror commented

@ChristopherHX commented on GitHub (May 18, 2023):

I would set to github.com in all my instances and I would strongly suggest the default to be adjusted to that.

Yes, I also think github.com is a better default than gitea.com.

I have modded my own actions_runner for gitea actions to look also on github.com to find actions.

@ChristopherHX commented on GitHub (May 18, 2023): > I would set to github.com in all my instances and I would strongly suggest the default to be adjusted to that. Yes, I also think github.com is a better default than gitea.com. I have modded my own actions_runner for gitea actions to look also on github.com to find actions.

GiteaMirror commented

@lunny commented on GitHub (May 18, 2023):

I don't think github.com is better than gitea.com. Because some actions may need to be changed which cannot be used directly by Gitea. i.e. All actions which depend on GitHub APIs which Gitea APIs doesn't compatible will be run failed. For those actions, we need to fork and adjust them.

Considering 3 different Gitea instances.

1 Public Gitea instances
2 Private network Gitea instances that could connect to Internet.
3 Private network Gitea instances that cannot connect to Internet.

To satisfy all three situations, a configurable item is necessary.
And of course, if we can support multiple sites(less than 3), maybe it's better.
For 1 and 2, it could use localhost, gitea.com, github.com
For 3, it could use localhost

@lunny commented on GitHub (May 18, 2023): I don't think github.com is better than gitea.com. Because some actions may need to be changed which cannot be used directly by Gitea. i.e. All actions which depend on GitHub APIs which Gitea APIs doesn't compatible will be run failed. For those actions, we need to fork and adjust them. Considering 3 different Gitea instances. 1 Public Gitea instances 2 Private network Gitea instances that could connect to Internet. 3 Private network Gitea instances that cannot connect to Internet. To satisfy all three situations, a configurable item is necessary. And of course, if we can support multiple sites(less than 3), maybe it's better. For 1 and 2, it could use `localhost, gitea.com, github.com` For 3, it could use `localhost`

GiteaMirror commented

@silverwind commented on GitHub (May 18, 2023):

Maybe we can have a vote:

1. 🎉 Set default to https://github.com
1. 🚀 Multiple prefixes, ["https://github.com", "https://gitea.com"]
1. ❤️ Set default to https://gitea.com

My option preference is 1 > 2, while 3 is unacceptable to me.

@silverwind commented on GitHub (May 18, 2023): Maybe we can have a vote: - 1. 🎉 Set default to `https://github.com` - 2. 🚀 Multiple prefixes, `["https://github.com", "https://gitea.com"]` - 3. ❤️ Set default to `https://gitea.com` My option preference is 1 > 2, while 3 is unacceptable to me.

GiteaMirror commented

@lunny commented on GitHub (May 18, 2023):

Maybe we can have a vote:
* 1. 🎉 Set default to `https://github.com`

* 2. 🚀 Multiple prefixes, `["https://github.com", "https://gitea.com"]`

* 3. ❤️ Set default to `https://gitea.com`
My option preference is 1 > 2, while 3 is unacceptable to me.

Please read my comment above.

@lunny commented on GitHub (May 18, 2023): > Maybe we can have a vote: > > * 1. 🎉 Set default to `https://github.com` > > * 2. 🚀 Multiple prefixes, `["https://github.com", "https://gitea.com"]` > > * 3. ❤️ Set default to `https://gitea.com` > > > My option preference is 1 > 2, while 3 is unacceptable to me. Please read my comment above.

GiteaMirror commented

@silverwind commented on GitHub (May 18, 2023):

Because some actions may need to be changed which cannot be used directly by Gitea. i.e. All actions which depend on GitHub APIs which Gitea APIs doesn't compatible will be run failed. For those actions, we need to fork and adjust them.

Yes, but fork them under a new name so that actions/foo unambiguosly refers to the action on github while https://gitea.com/actions/foo refers to the one one gitea. This is how it works in docker where image namefoo essentially always refers to docker.io/foo, and not another registry.

If we could convince GitHub to support a prefix, those actions would be even runnable (if compatible) on github.com.

@silverwind commented on GitHub (May 18, 2023): > Because some actions may need to be changed which cannot be used directly by Gitea. i.e. All actions which depend on GitHub APIs which Gitea APIs doesn't compatible will be run failed. For those actions, we need to fork and adjust them. Yes, but fork them under a new name so that `actions/foo` unambiguosly refers to the action on github while `https://gitea.com/actions/foo` refers to the one one gitea. This is how it works in docker where image name`foo` essentially always refers to `docker.io/foo`, and not another registry. If we could convince GitHub to support a prefix, those actions would be even runnable (if compatible) on github.com.

GiteaMirror commented

@silverwind commented on GitHub (May 18, 2023):

Private network Gitea instances that cannot connect to Internet.

This is a valid concern, and a https://localhost entry would be need to set there, but it should not be the default.

@silverwind commented on GitHub (May 18, 2023): > Private network Gitea instances that cannot connect to Internet. This is a valid concern, and a `https://localhost` entry would be need to set there, but it should not be the default.

GiteaMirror commented

@lunny commented on GitHub (May 18, 2023):

👍 Could I vote ["https://gitea.com", "https://github.com"]? So that we can override some non-compatible actions in github.com. Users' workflows could run both successes without changes.

@lunny commented on GitHub (May 18, 2023): 👍 Could I vote `["https://gitea.com", "https://github.com"]`? So that we can override some non-compatible actions in github.com. Users' workflows could run both successes without changes.

GiteaMirror commented

@silverwind commented on GitHub (May 18, 2023):

While not ideal, ["https://gitea.com", "https://github.com"] for the default seems like an acceptable compromise to me which will satisfy most scenarios.

@silverwind commented on GitHub (May 18, 2023): While not ideal, `["https://gitea.com", "https://github.com"]` for the default seems like an acceptable compromise to me which will satisfy most scenarios.

GiteaMirror commented

@silverwind commented on GitHub (May 18, 2023):

I think we could extend DEFAULT_ACTIONS_URL with a comma syntax as comma is unlikely to appear in an URL, e.g.

DEFAULT_ACTIONS_URL = https://gitea.com, https://github.com

Trailing slash should be stripped while parsing the setting and subsequent URL join should be with /.

@silverwind commented on GitHub (May 18, 2023): I think we could extend `DEFAULT_ACTIONS_URL` with a comma syntax as comma is unlikely to appear in an URL, e.g. ``` DEFAULT_ACTIONS_URL = https://gitea.com, https://github.com ``` Trailing slash should be stripped while parsing the setting and subsequent URL join should be with `/`.

GiteaMirror commented

@silverwind commented on GitHub (May 19, 2023):

I think we should also put out a recommendation to always use FQANs (fully qualified action names), eliminiating any ambiguity on where the action is hosted, e.g.

https://github.com/actions/setup-python@4

instead of the ambiguous

actions/setup-python@4

We should also push github to support the FQAN syntax, as currently it's not possible to use actions hosted anywhere else than github.

@silverwind commented on GitHub (May 19, 2023): I think we should also put out a recommendation to always use FQANs (fully qualified action names), eliminiating any ambiguity on where the action is hosted, e.g. ``` https://github.com/actions/setup-python@4 ``` instead of the ambiguous ``` actions/setup-python@4 ``` We should also push github to support the FQAN syntax, as currently it's not possible to use actions hosted anywhere else than github.

GiteaMirror commented

@silverwind commented on GitHub (May 19, 2023):

Another idea that comes to mind: docker images names omit the https:// prefix, and I think this is something worth considering too. I think it should be possible to enforce that all actions should be hosted on https only, e.g. no http. This benefits both security and is less to type.

@silverwind commented on GitHub (May 19, 2023): Another idea that comes to mind: docker images names omit the `https://` prefix, and I think this is something worth considering too. I think it should be possible to enforce that all actions should be hosted on `https` only, e.g. no `http`. This benefits both security and is less to type.

GiteaMirror commented

@yardenshoham commented on GitHub (May 19, 2023):

Yes, that also feels more like docker

@yardenshoham commented on GitHub (May 19, 2023): Yes, that also feels more like docker

GiteaMirror commented

@silverwind commented on GitHub (May 19, 2023):

Should be easy to accept all three forms:

https://github.com/actions/setup-python@4 # take as-is
github.com/actions/setup-python@4 # add 'https://' prefix
actions/setup-python@4 # resolve via DEFAULT_ACTIONS_URL

@silverwind commented on GitHub (May 19, 2023): Should be easy to accept all three forms: ```bash https://github.com/actions/setup-python@4 # take as-is github.com/actions/setup-python@4 # add 'https://' prefix actions/setup-python@4 # resolve via DEFAULT_ACTIONS_URL ```

GiteaMirror commented

@ChristopherHX commented on GitHub (May 19, 2023):

github.com/actions/setup-python@4 # add 'https://' prefix

Allowing this is dangerous in my opinion (it has been proposed like this already)
Then you need a very smart parser to parse

<domain>/<owner/<repository>/<path>@<version>
<owner/<repository>/<path>@<version> github actions syntax, path can contain multiple / or omitted

@ChristopherHX commented on GitHub (May 19, 2023): > `github.com/actions/setup-python@4 # add 'https://' prefix` Allowing this is dangerous in my opinion (it has been proposed like this already) Then you need a very smart parser to parse - `<domain>/<owner/<repository>/<path>@<version>` - `<owner/<repository>/<path>@<version>` _github actions syntax, path can contain multiple `/` or omitted_

GiteaMirror commented

@silverwind commented on GitHub (May 19, 2023):

github actions syntax, path can contain multiple / or omitted

Ah, didn't know that action can be in subdirectories of a repo, yes that makes it ambiguous to parse, so probably don't support that variant.

@silverwind commented on GitHub (May 19, 2023): > github actions syntax, path can contain multiple / or omitted Ah, didn't know that action can be in subdirectories of a repo, yes that makes it ambiguous to parse, so probably don't support that variant.

GiteaMirror commented

@silverwind commented on GitHub (Jun 23, 2023):

I was toying with the idea of making updates support updating actions to latest versions locally, but given that the DEFAULT_ACTIONS_URL mechanism makes action URLs ambigous depending on instance configuration, it'll break in cases when DEFAULT_ACTIONS_URL is not https://github.com because DEFAULT_ACTIONS_URL is only resolved at the Gitea server, not the user's machine.

So I still strongly recommend we:

Set DEFAULT_ACTIONS_URL to https://github.com by default, or even better, eliminate the option it completely so instances can not be configured to resolve action names ambigously
Clearly document that non-GitHub-hosted actions need to be specified as FQAN
Convince GitHub to support FQANs, making it possible to use Gitea-hosted actions on Github Actions

This will ensure that when/if Gitea actions becomes popular, action names will always be unambigous globally and users can seamlessly share actions between GitHub and Gitea instances. It will require a bit more verbose syntax, but I think it's only for the better:

Use actions/checkout@v3 to refer to the github.com action
Use https://gitea.com/actions/checkout@v3 to refer to the gitea.com action
Use https://codeberg.org/actions/checkout@v3 to refer to the codeberg.org action

@silverwind commented on GitHub (Jun 23, 2023): I was toying with the idea of making [updates](https://github.com/silverwind/updates) support updating actions to latest versions locally, but given that the `DEFAULT_ACTIONS_URL` mechanism makes action URLs ambigous depending on instance configuration, it'll break in cases when `DEFAULT_ACTIONS_URL` is not `https://github.com` because `DEFAULT_ACTIONS_URL` is only resolved at the Gitea server, not the user's machine. So I still strongly recommend we: - Set `DEFAULT_ACTIONS_URL` to `https://github.com` by default, or even better, eliminate the option it completely so instances can not be configured to resolve action names ambigously - Clearly document that non-GitHub-hosted actions need to be specified as FQAN - Convince GitHub to support FQANs, making it possible to use Gitea-hosted actions on Github Actions This will ensure that when/if Gitea actions becomes popular, action names will always be unambigous globally and users can seamlessly share actions between GitHub and Gitea instances. It will require a bit more verbose syntax, but I think it's only for the better: - Use `actions/checkout@v3` to refer to the github.com action - Use `https://gitea.com/actions/checkout@v3` to refer to the gitea.com action - Use `https://codeberg.org/actions/checkout@v3` to refer to the codeberg.org action

GiteaMirror commented

@silverwind commented on GitHub (Jun 23, 2023):

So I would propose the following course of actions:

Default DEFAULT_ACTIONS_URL to https://github.com in the next version
Deprecate DEFAULT_ACTIONS_URL in the runner in the next version
Remove DEFAULT_ACTIONS_URL in the runner in the following version

The minor inconvenience of adding https:/gitea.com to all action names is meager in comparison to breaking the nascent actions ecosystem as a whole. Without this change, GitHub's runner would not be able to resolve gitea-hosted actions.

@silverwind commented on GitHub (Jun 23, 2023): So I would propose the following course of actions: - Default `DEFAULT_ACTIONS_URL` to `https://github.com` in the next version - Deprecate `DEFAULT_ACTIONS_URL` in the runner in the next version - Remove `DEFAULT_ACTIONS_URL` in the runner in the following version The minor inconvenience of adding `https:/gitea.com` to all action names is meager in comparison to breaking the nascent actions ecosystem as a whole. Without this change, GitHub's runner would not be able to resolve gitea-hosted actions.

GiteaMirror commented

@lunny commented on GitHub (Jun 23, 2023):

I don't think runner support DEFAULT_ACTIONS_URL?

@lunny commented on GitHub (Jun 23, 2023): I don't think runner support `DEFAULT_ACTIONS_URL`?

GiteaMirror commented

2025-11-02 09:20:41 -06:00

@wolfogre commented on GitHub (Jun 25, 2023):

Set DEFAULT_ACTIONS_URL to https://github.com by default, or even better, eliminate the option it completely so instances can not be configured to resolve action names ambigously

Clearly document that non-GitHub-hosted actions need to be specified as FQAN

Convince GitHub to support FQANs, making it possible to use Gitea-hosted actions on Github Actions

This will ensure that when/if Gitea actions becomes popular, action names will always be unambigous globally and users can seamlessly share actions between GitHub and Gitea instances. It will require a bit more verbose syntax, but I think it's only for the better:

Use actions/checkout@v3 to refer to the github.com action

Use https://gitea.com/actions/checkout@v3 to refer to the gitea.com action

Use https://codeberg.org/actions/checkout@v3 to refer to the codeberg.org action

I agree with @silverwind. We had to use DEFAULT_ACTIONS_URL because the act runner did not support uses: https://gitea.com/xxx at first, but now, the confusion it brings is greater than the convenience it brings.

@wolfogre commented on GitHub (Jun 25, 2023): > * Set `DEFAULT_ACTIONS_URL` to `https://github.com` by default, or even better, eliminate the option it completely so instances can not be configured to resolve action names ambigously > * Clearly document that non-GitHub-hosted actions need to be specified as FQAN > * Convince GitHub to support FQANs, making it possible to use Gitea-hosted actions on Github Actions > > This will ensure that when/if Gitea actions becomes popular, action names will always be unambigous globally and users can seamlessly share actions between GitHub and Gitea instances. It will require a bit more verbose syntax, but I think it's only for the better: > > * Use `actions/checkout@v3` to refer to the github.com action > * Use `https://gitea.com/actions/checkout@v3` to refer to the gitea.com action > * Use `https://codeberg.org/actions/checkout@v3` to refer to the codeberg.org action I agree with @silverwind. We had to use `DEFAULT_ACTIONS_URL` because the act runner did not support `uses: https://gitea.com/xxx` at first, but now, the confusion it brings is greater than the convenience it brings.

GiteaMirror commented

@techknowlogick commented on GitHub (Jun 25, 2023):

This sounds like a reasonable approach to me too

@techknowlogick commented on GitHub (Jun 25, 2023): This sounds like a reasonable approach to me too

GiteaMirror commented

2025-11-02 09:20:41 -06:00

@silverwind commented on GitHub (Jun 26, 2023):

I don't think runner support DEFAULT_ACTIONS_URL?

Is it a gitea-only setting and gitea communicates the absolute URL to the runner?

da6df0d063/modules/setting/actions.go (L16)

I think we should get DEFAULT_ACTIONS_URL=https://github.com into v1.21, and likely document for v1.20 that the default will change next version. Then maybe deprecate the setting in v1.22 or later, but no pressure on that one.

@silverwind commented on GitHub (Jun 26, 2023): > I don't think runner support `DEFAULT_ACTIONS_URL`? Is it a gitea-only setting and gitea communicates the absolute URL to the runner? https://github.com/go-gitea/gitea/blob/da6df0d0636c9e7bb5481e41dcd7d8f9b46deed5/modules/setting/actions.go#L16 I think we should get `DEFAULT_ACTIONS_URL=https://github.com` into v1.21, and likely document for v1.20 that the default will change next version. Then maybe deprecate the setting in v1.22 or later, but no pressure on that one.

GiteaMirror commented

2025-11-02 09:20:41 -06:00

@wolfogre commented on GitHub (Jun 29, 2023):

I find a very strong reason to make some changes for DEFAULT_ACTIONS_URL. It's about security so we will talk about it in private.

@silverwind Discord please.

@wolfogre commented on GitHub (Jun 29, 2023): I find a very strong reason to make some changes for `DEFAULT_ACTIONS_URL`. It's about security so we will talk about it in private. @silverwind Discord please.

GiteaMirror commented

@silverwind commented on GitHub (Jun 29, 2023):

Don't have time right now, but will check it later there.

@silverwind commented on GitHub (Jun 29, 2023): Don't have time right now, but will check it later there.

GiteaMirror commented

@silverwind commented on GitHub (Jun 29, 2023):

One niceity we can allow ommitting the protocol, so github.com prefix is equal to https://github.com etc. It saves a bit of typing and is still unambiguous because after the URL origin, the user/repo format is always to strings separated by /. This is also how docker does it, but I'm of the opinion we should support both with and without protocol.

@silverwind commented on GitHub (Jun 29, 2023): One niceity we can allow ommitting the protocol, so `github.com` prefix is equal to `https://github.com` etc. It saves a bit of typing and is still unambiguous because after the URL origin, the `user/repo` format is always to strings separated by `/`. This is also how docker does it, but I'm of the opinion we should support both with and without protocol.

GiteaMirror commented

@wolfogre commented on GitHub (Jun 29, 2023):

but I'm of the opinion we should support both with and without protocol.

I understand, that's what I thought at the beginning, but unfortunately GitHub Actions already support uses: x/y/z, and z means sub folder, like use: actions/cache/restore@v3.

So it's tricky to distinguish between host/user/repo and user/repo/folder.

Update:

Maybe we could and a leading / like /host/user/repo, but it could mislead users because it's easy to think that the leading '/' means nothing or it's just a typo.

@wolfogre commented on GitHub (Jun 29, 2023): > but I'm of the opinion we should support both with and without protocol. I understand, that's what I thought at the beginning, but unfortunately GitHub Actions already support `uses: x/y/z`, and `z` means sub folder, like `use: actions/cache/restore@v3`. So it's tricky to distinguish between `host/user/repo` and `user/repo/folder`. --- Update: Maybe we could and a leading `/` like `/host/user/repo`, but it could mislead users because it's easy to think that the leading '/' means nothing or it's just a typo.

GiteaMirror commented

@yardenshoham commented on GitHub (Jun 29, 2023):

docker treats it as a host if it has . or :, otherwise it's a user

@yardenshoham commented on GitHub (Jun 29, 2023): docker treats it as a host if it has `.` or `:`, otherwise it's a user

GiteaMirror commented

@wolfogre commented on GitHub (Jun 29, 2023):

docker treats it as a host if it has . or :, otherwise it's a user

Not ideal for this, what if https://gitea.com/test.com/test?

@wolfogre commented on GitHub (Jun 29, 2023): > docker treats it as a host if it has `.` or `:`, otherwise it's a user Not ideal for this, what if `https://gitea.com/test.com/test`?

GiteaMirror commented

@yardenshoham commented on GitHub (Jun 29, 2023):

It'll be the action test.com/test from the https://gitea.com instance

@yardenshoham commented on GitHub (Jun 29, 2023): It'll be the action `test.com/test` from the `https://gitea.com` instance

GiteaMirror commented

@silverwind commented on GitHub (Jun 29, 2023):

Unfortunatly, gitea allows usernames with ., making it ambigous again with hostname. I think we should forbid . in at least new usernames.

FTR: Github forbids . in username. Reference. I would even go as far as adopt that regex in gitea.

@silverwind commented on GitHub (Jun 29, 2023): Unfortunatly, gitea allows usernames with `.`, making it ambigous again with hostname. I think we should forbid `.` in at least new usernames. FTR: Github forbids `.` in username. [Reference](https://github.com/shinnn/github-username-regex/blob/master/index.js). I would even go as far as adopt that regex in gitea.

GiteaMirror commented

@wolfogre commented on GitHub (Jun 29, 2023):

. is not the point (although it is a "point" 😂). Even though GitHub/Gitea/GitLab/GitXX all forbid . in usernames, users can still use use custom git server which we never heard to host actions, right?

And it is also possible for hostname not to contain ., what if localhost or others hostnames definded in /etc/hosts? And the service names in docker-compose.yaml are available hostnames

@wolfogre commented on GitHub (Jun 29, 2023): `.` is not the point (although it is a "point" 😂). Even though GitHub/Gitea/GitLab/GitXX all forbid `.` in usernames, users can still use use custom git server which we never heard to host actions, right? And it is also possible for hostname not to contain `.`, what if `localhost` or others hostnames definded in `/etc/hosts`? And the service names in `docker-compose.yaml` are available hostnames

GiteaMirror commented

@yardenshoham commented on GitHub (Jun 29, 2023):

You'd do something like localhost:80

@yardenshoham commented on GitHub (Jun 29, 2023): You'd do something like `localhost:80`

GiteaMirror commented

@ChristopherHX commented on GitHub (Jun 29, 2023):

users can still use use custom git server which we never heard to host actions, right?

I want to note that only act and it's derviates clone actions via git.

actions/runner downloads tar / zip archives via api after asking the GitHub Instance where it is located (GitHub also applies an allowed repository filter and sends a token to authorized private actions for private repos), which is faster than a full unshallow git clone on a microSD

Also the git only server would have to follow the <owner>/<repo> pattern, I saw some using a completly different url path and wouldn't work either way.

You'd do something like localhost:80

Since port 80 is http by default, would this mean like docker it contact the server via http and switch after a redirect to https? I thought that the outcome was strict https for short notation

And the service names in docker-compose.yaml are available hostnames

Same question, not everyone uses https within docker compose.

Eventually you have to fallback to the http/https notation in these cases.

@ChristopherHX commented on GitHub (Jun 29, 2023): > users can still use use custom git server which we never heard to host actions, right? I want to note that only act and it's derviates clone actions via git. actions/runner downloads tar / zip archives via api after asking the GitHub Instance where it is located (GitHub also applies an allowed repository filter and sends a token to authorized private actions for private repos), which is faster than a full unshallow git clone on a microSD Also the git only server would have to follow the `<owner>/<repo>` pattern, I saw some using a completly different url path and wouldn't work either way. > You'd do something like localhost:80 Since port 80 is http by default, would this mean like docker it contact the server via http and switch after a redirect to https? I thought that the outcome was strict https for short notation > And the service names in docker-compose.yaml are available hostnames Same question, not everyone uses https within docker compose. Eventually you have to fallback to the http/https notation in these cases.

GiteaMirror commented

@wolfogre commented on GitHub (Jun 29, 2023):

To be clear, I agree with any solution that can shorten the path of actions, as long as:

schema://host/user/name still works, so that the user can still make it clear. And it is also possible to support more schemas, such as file://.
No ambiguity, and no additional operations are required to disambiguate. For example, host/user/name means default_schema://host/user/name , but if the host does not contain ., you must add the port to the host.
No guessing . For example, don't do something like pinging the hostname to check if it is a valid hostname.

Unfortunately, I cannot figure out a solution to omit protocol if the format is x/y/z.

@wolfogre commented on GitHub (Jun 29, 2023): To be clear, I agree with any solution that can shorten the path of actions, as long as: - `schema://host/user/name` still works, so that the user can still make it clear. And it is also possible to support more schemas, such as `file://`. - No ambiguity, and no additional operations are required to disambiguate. For example, `host/user/name` means `default_schema://host/user/name` , but if the host does not contain `.`, you must add the port to the host. - No guessing . For example, don't do something like pinging the hostname to check if it is a valid hostname. Unfortunately, I cannot figure out a solution to omit protocol if the format is `x/y/z`.

GiteaMirror commented

@ghnp5 commented on GitHub (Jul 16, 2023):

Hey!

I believe I understand why this change was made, and I'm happy to keep the default to "github".

However, I'd like to understand whether this means I should prefer the GitHub Actions instead of Gitea Actions, when referring to uses:.

For example, you mirrored a few actions, such as checkout.
Is it OK to use GitHub's version instead of Gitea's version?

Also, there are several actions in the marketplace that use the Octokit library, which I always believed I should avoid those, because they only work for GitHub and not Gitea, am I correct to say that?

I'm just wondering how "safe" it is to default to GitHub, hoping that I will never use an action from GitHub by accident, that could potentially damage my repos or Gitea instance, due to incompatibilities (when Gitea's mirror version would be more compatible).

Apologies if something of what I said above doesn't make sense :)

Thank you!

@ghnp5 commented on GitHub (Jul 16, 2023): Hey! I believe I understand why this change was made, and I'm happy to keep the default to "github". However, I'd like to understand whether this means I should prefer the GitHub Actions instead of Gitea Actions, when referring to `uses:`. For example, you mirrored a few actions, such as `checkout`. Is it OK to use GitHub's version instead of Gitea's version? Also, there are several actions in the marketplace that use the Octokit library, which I always believed I should avoid those, because they only work for GitHub and not Gitea, am I correct to say that? I'm just wondering how "safe" it is to default to GitHub, hoping that I will never use an action from GitHub by accident, that could potentially damage my repos or Gitea instance, due to incompatibilities (when Gitea's mirror version would be more compatible). Apologies if something of what I said above doesn't make sense :) Thank you!

GiteaMirror commented

@wolfogre commented on GitHub (Jul 17, 2023):

For example, you mirrored a few actions, such as checkout. Is it OK to use GitHub's version instead of Gitea's version?

IIRC, yes, the mirror is just a mirror.

Also, there are several actions in the marketplace that use the Octokit library, which I always believed I should avoid those, because they only work for GitHub and not Gitea, am I correct to say that?

Not really, of course the Octokit library is designed for GitHub not Gitea, however, Gitea has a certain degree of compatibility with GitHub, so I would say that most actions can be used on Gitea, even though they are developed based on Octokit. However, I cannot guarantee that all actions will be compatible. We are also working on identifying incompatible actions and making them compatible, but you know, it's a big task.

@wolfogre commented on GitHub (Jul 17, 2023): > For example, you mirrored a few actions, such as `checkout`. Is it OK to use GitHub's version instead of Gitea's version? IIRC, yes, the mirror is just a mirror. > Also, there are several actions in the marketplace that use the Octokit library, which I always believed I should avoid those, because they only work for GitHub and not Gitea, am I correct to say that? Not really, of course the Octokit library is designed for GitHub not Gitea, however, Gitea has a certain degree of compatibility with GitHub, so I would say that most actions can be used on Gitea, even though they are developed based on Octokit. However, I cannot guarantee that all actions will be compatible. We are also working on identifying incompatible actions and making them compatible, but you know, it's a big task.

GiteaMirror commented