Skip to content

enable usage of absolute urls for reusable workflows #30246

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jonas-switala opened this issue Apr 2, 2024 · 3 comments
Closed

enable usage of absolute urls for reusable workflows #30246

jonas-switala opened this issue Apr 2, 2024 · 3 comments
Labels
proposal/accepted We have reviewed the proposal and agree that it should be implemented like that/at all. topic/gitea-actions related to the actions of Gitea type/proposal The new feature has not been accepted yet but needs to be discussed first.

Comments

@jonas-switala
Copy link

Feature Description

Reusing workflows seems quite similar to reusing actions at first glance. They share several common issues. For example:

  • Accessing workflows/actions from private repositories
  • Distinguishing workflows/actions hosted on github.com or locally

For actions, this issue can be resolved by using absolute URLs (As described here https://docs.gitea.com/next/usage/actions/comparison#absolute-action-urls) and embedding the access token (As described in #25929)
However, this is currently not supported for reusable workflows:

calling workflow snippet:

### jobs:
  validate-manifests:
    uses: https://${{ secrets.GITHUB_TOKEN }}:{instance}/{owner}/{repo}/.gitea/workflows/[email protected]

output:

expected format {owner}/{repo}/.{git_platform}/workflows/{filename}@{ref}. Actual 'https://${{ secrets.GITHUB_TOKEN }}:{instance}/{owner}/{repo}/.gitea/workflows/[email protected]' Input string was not in a correct format

This leads to several inconveniences when working with reusable workflows or even makes them unusable for some use cases:

  • reusable workflows can't be hosted in private repos since there is no way to use a token with sufficient permissions
  • the only way to use reusable workflows not hosted publically on github.com is to set DEFAULT_ACTIONS_URL=self which
    • requires absolute URLs for all GitHub-hosted actions on the Gitea instance (which might be the majority of actions)
    • prohibts users from using reusable workflows hosted on github.com, since without absolute URLs there is no way to specify where a reusable workflow might be hosted

Possible Solution

I think the cleanest way to solve this is to make the same URL options available for reusable workflows that are already implemented for actions (e.g. absolute URLs with embedded tokens)

Screenshots

No response

@jonas-switala jonas-switala added the type/proposal The new feature has not been accepted yet but needs to be discussed first. label Apr 2, 2024
@silverwind
Copy link
Member

silverwind commented Apr 2, 2024

Indeed we have to support the same URL prefix mechanism like we do on actions, e.g. in the default configuration, assume a https://github.com/ prefix for unprefixed specifiers.

@silverwind silverwind added the proposal/accepted We have reviewed the proposal and agree that it should be implemented like that/at all. label Apr 2, 2024
@Zettat123
Copy link
Contributor

Hi @jonas-switala , using absolute URLs for reusable workflows is already supported by gitea/act#104. Could you try the new version of act_runner?

@silverwind silverwind added the topic/gitea-actions related to the actions of Gitea label Apr 24, 2024
@jonas-switala
Copy link
Author

I finally found some time to test this and can confirm that the absolute URLs work (using gitea v1.22.3 and act-runner v0.2.10). I still have some problems using the embedded token for auth, but I think that is a better fit for this issue: #25929.
As far as I am concerned this issue can be treated as fixed. Thanks to everyone involved :)

@go-gitea go-gitea locked as resolved and limited conversation to collaborators Feb 9, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
proposal/accepted We have reviewed the proposal and agree that it should be implemented like that/at all. topic/gitea-actions related to the actions of Gitea type/proposal The new feature has not been accepted yet but needs to be discussed first.
Projects
None yet
Development

No branches or pull requests

3 participants