Actions - Inconsistency accessing user's variables and secrets #30361
Comments
It shouldn't be, if you set a variable or secret for a user, then the repo belonging to an org cannot read it, regardless of whether the user is the creator of the repo or a member of the org. So what surprised me is:
It shouldn't be, and I tried to reproduce it in my local environment. Please point out which step should be adjusted.
This is as expected. |
Thank you for the clarification.
I'd say the steps are correct. I tried reproducing it again, and I got the same output (see screenshot).
My steps:
I also tried running the action with a different user (non-root). I added the user to the collaborators of the "test_repo", set the same variable with value "tester-user2", and I got the same behaviour. Same happens when adding the second user to an org's team with write permissions to the code, instead of the collaborators.
Let me know what I can share to dig deeper into the issue. |
TBH, I think there's no way to do that. And I don't think it could be supported by Gitea or even GitHub. It could make the workflows very fragile when sometimes the variable/secret is A while sometimes it is B. And it's also unsafe, since the actor could be a collaborator. How can the owner of a repo ask their collaborators to share their secrets? Just a joke: Hi QuantumQuacken, I would like to invite you to my personal project. Please commit to my repo, and the scripts will send all your secrets to my email. 😄
Could you please check:
|
It's a new topic for me, so thank you very much for the explanation! test_repo variables: test_org variables: I can't see any variables section in the Admin settings. Was it added in 1.22 or later? |
Sorry, I was mistaken. You are right, it was added in v1.22. Thank you for patiently providing such a detailed troubleshooting process. In the end, I identified the bug. |
Fix #30361, regression of #29782 which is a backport, not the original #29468. #29468 did a small refactor which introduced a new function `GetVariablesOfRun`. However, it's designed for v1.22 which supports global variables. After backporting it to v1.21, it will still try to get global variables, which causes it to retrieve all variables.
|
Closed by #30402 |
Description
Hello,
I'm trying to implement a CI/CD pipeline using Gitea Actions, and I found an inconsistent behaviour when accessing user variables and secrets.
I set up a variable named USERNAME_VARIABLE with value tester-user, a secret named USERNAME_SECRET with value tester-user, both on the user, and a simple workflow:
With a repository owned by an organization, with no variables or secrets on the ORG or REPO level, the output of the workflow is:
Same case, with the USERNAME_SECRET set on the ORG, the output is:
The inconsistency is the action being able to access a user's variable, but not a user's secret. I'd expect the action being able to access the user's secrets, the same way it does for variables.
In other words:
The variable is available when requested, because it's found on the user's variables (expected).
The secret is not available (empty string) when requested, even if it's on the user's secrets (not expected). The secret is only available when the owner of the repository (an org or an user) has the required secrets.
Is the expected behaviour, or is it not correct?
Set up job of the workflow:
If something is not clear or detailed enough, please let me know so I can add the appropriate information.
Gitea Version
1.21.10
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
No response
Git Version
2.39.2
Operating System
Debian GNU/Linux 12 (bookworm) - Linux 6.1.0-17-amd64
How are you running Gitea?
My Gitea instance is running using the binary downloaded from GitHub. I installed the instance as described in the docs and set it up as a service as described here.
I'm using act-runner v0.2.6 in Docker 26.0.0 build 2ae903e.
Database
PostgreSQL
The text was updated successfully, but these errors were encountered: