github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-12 02:24:21 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Actions - Inconsistency accessing user's variables and secrets #12805

New Issue
Closed
opened 2025-11-02 10:21:32 -06:00 by GiteaMirror · 6 comments
GiteaMirror commented 2025-11-02 10:21:32 -06:00
Owner
Copy Link

Originally created by @QuantumQuacken on GitHub (Apr 9, 2024).

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:

name: Test Secrets and Vars
on:
  push:
    branches: [main]
  
jobs:
  build:
    runs-on: [ubuntu-latest]
    container:
      image: catthehacker/ubuntu:mod-hosts
    steps:
      - name: Print secret and var
        run: |
          echo "Username var: ${{ vars.USERNAME_VARIABLE }}"
          echo "Username secret: ${{ secrets.USERNAME_SECRET }}"

With a repository owned by an organization, with no variables or secrets on the ORG or REPO level, the output of the workflow is:

Username var: tester-user
Username secret:

Same case, with the USERNAME_SECRET set on the ORG, the output is:

Username var: tester-user
Username secret: ***

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: 
2024-04-09T08:33:35.9732276Z testRunner(version:v0.2.6) received task 297 of job 316, be triggered by event: push
2024-04-09T08:33:35.9748040Z workflow prepared
2024-04-09T08:33:35.9750946Z evaluating expression 'success()'
2024-04-09T08:33:35.9753135Z expression 'success()' evaluated to 'true'
2024-04-09T08:33:35.9753595Z 🚀  Start image=catthehacker/ubuntu:mod-hosts
2024-04-09T08:33:35.9867221Z   🐳  docker pull image=catthehacker/ubuntu:mod-hosts platform= username= forcePull=false
2024-04-09T08:33:35.9867396Z   🐳  docker pull catthehacker/ubuntu:mod-hosts
2024-04-09T08:33:35.9887351Z Image exists? true
2024-04-09T08:33:36.0954194Z   🐳  docker create image=catthehacker/ubuntu:mod-hosts platform= entrypoint=["/bin/sleep" "10800"] cmd=[]
2024-04-09T08:33:36.1022365Z Common container.Config ==> &{Hostname: Domainname: User: AttachStdin:false AttachStdout:false AttachStderr:false ExposedPorts:map[] Tty:false OpenStdin:false StdinOnce:false Env:[RUNNER_TOOL_CACHE=/opt/hostedtoolcache RUNNER_OS=Linux RUNNER_ARCH=X64 RUNNER_TEMP=/tmp LANG=C.UTF-8] Cmd:[] Healthcheck:<nil> ArgsEscaped:false Image:catthehacker/ubuntu:mod-hosts Volumes:map[] WorkingDir:/workspace/digital/supBack Entrypoint:[] NetworkDisabled:false MacAddress: OnBuild:[] Labels:map[] StopSignal: StopTimeout:<nil> Shell:[]}
2024-04-09T08:33:36.1137538Z Common container.HostConfig ==> &{Binds:[/var/run/docker.sock:/var/run/docker.sock] ContainerIDFile: LogConfig:{Type: Config:map[]} NetworkMode:GITEA-ACTIONS-TASK-297_WORKFLOW-Test-Secrets-and-Vars_JOB-build-network PortBindings:map[] RestartPolicy:{Name: MaximumRetryCount:0} AutoRemove:true VolumeDriver: VolumesFrom:[] ConsoleSize:[0 0] Annotations:map[] CapAdd:[] CapDrop:[] CgroupnsMode: DNS:[] DNSOptions:[] DNSSearch:[] ExtraHosts:[] GroupAdd:[] IpcMode: Cgroup: Links:[] OomScoreAdj:0 PidMode: Privileged:false PublishAllPorts:false ReadonlyRootfs:false SecurityOpt:[] StorageOpt:map[] Tmpfs:map[] UTSMode: UsernsMode: ShmSize:0 Sysctls:map[] Runtime: Isolation: Resources:{CPUShares:0 Memory:0 NanoCPUs:0 CgroupParent: BlkioWeight:0 BlkioWeightDevice:[] BlkioDeviceReadBps:[] BlkioDeviceWriteBps:[] BlkioDeviceReadIOps:[] BlkioDeviceWriteIOps:[] CPUPeriod:0 CPUQuota:0 CPURealtimePeriod:0 CPURealtimeRuntime:0 CpusetCpus: CpusetMems: Devices:[] DeviceCgroupRules:[] DeviceRequests:[] KernelMemory:0 KernelMemoryTCP:0 MemoryReservation:0 MemorySwap:0 MemorySwappiness:<nil> OomKillDisable:<nil> PidsLimit:<nil> Ulimits:[] CPUCount:0 CPUPercent:0 IOMaximumIOps:0 IOMaximumBandwidth:0} Mounts:[{Type:volume Source:GITEA-ACTIONS-TASK-297_WORKFLOW-Test-Secrets-and-Vars_JOB-build Target:/workspace/digital/supBack ReadOnly:false Consistency: BindOptions:<nil> VolumeOptions:<nil> TmpfsOptions:<nil> ClusterOptions:<nil>} {Type:volume Source:act-toolcache Target:/toolcache ReadOnly:false Consistency: BindOptions:<nil> VolumeOptions:<nil> TmpfsOptions:<nil> ClusterOptions:<nil>} {Type:volume Source:GITEA-ACTIONS-TASK-297_WORKFLOW-Test-Secrets-and-Vars_JOB-build-env Target:/var/run/act ReadOnly:false Consistency: BindOptions:<nil> VolumeOptions:<nil> TmpfsOptions:<nil> ClusterOptions:<nil>}] MaskedPaths:[] ReadonlyPaths:[] Init:<nil>}
2024-04-09T08:33:36.2710536Z Created container name=GITEA-ACTIONS-TASK-297_WORKFLOW-Test-Secrets-and-Vars_JOB-build id=669befa3a5a42b5e6bae1067779f191cb142dbe63abc6537ab0d51176d37a077 from image catthehacker/ubuntu:mod-hosts (platform: )
2024-04-09T08:33:36.2710950Z ENV ==> [RUNNER_TOOL_CACHE=/opt/hostedtoolcache RUNNER_OS=Linux RUNNER_ARCH=X64 RUNNER_TEMP=/tmp LANG=C.UTF-8]
2024-04-09T08:33:36.2711117Z   🐳  docker run image=catthehacker/ubuntu:mod-hosts platform= entrypoint=["/bin/sleep" "10800"] cmd=[]
2024-04-09T08:33:36.2711229Z Starting container: 669befa3a5a42b5e6bae1067779f191cb142dbe63abc6537ab0d51176d37a077
2024-04-09T08:33:36.5270495Z Started container: 669befa3a5a42b5e6bae1067779f191cb142dbe63abc6537ab0d51176d37a077
2024-04-09T08:33:36.6712413Z Writing entry to tarball workflow/event.json len:4217
2024-04-09T08:33:36.6713296Z Writing entry to tarball workflow/envs.txt len:0
2024-04-09T08:33:36.6713569Z Extracting content to '/var/run/act/'
2024-04-09T08:33:36.7119767Z setupEnv => map[ACT:true ACTIONS_CACHE_URL:http://172.17.0.2:41349/ ACTIONS_RUNTIME_TOKEN:*** ACTIONS_RUNTIME_URL:http://REDACTED:3000/api/actions_pipeline/ A_TEST_ENV_NAME_1:a_test_env_value_1 A_TEST_ENV_NAME_2:a_test_env_value_2 CI:true GITEA_ACTIONS:true GITEA_ACTIONS_RUNNER_VERSION:v0.2.6 GITHUB_ACTION:0 GITHUB_ACTIONS:true GITHUB_ACTION_PATH: GITHUB_ACTION_REF: GITHUB_ACTION_REPOSITORY: GITHUB_ACTOR:tester GITHUB_API_URL:http://REDACTED:3000/api/v1 GITHUB_BASE_REF: GITHUB_EVENT_NAME:push GITHUB_EVENT_PATH:/var/run/act/workflow/event.json GITHUB_GRAPHQL_URL: GITHUB_HEAD_REF: GITHUB_JOB:build GITHUB_REF:refs/heads/main GITHUB_REF_NAME:main GITHUB_REF_TYPE:branch GITHUB_REPOSITORY:digital/supBack GITHUB_REPOSITORY_OWNER:digital GITHUB_RETENTION_DAYS: GITHUB_RUN_ID:219 GITHUB_RUN_NUMBER:25 GITHUB_SERVER_URL:http://REDACTED:3000 GITHUB_SHA:7b37b5765defe012936001b3b6e718e47248c01d GITHUB_TOKEN:*** GITHUB_WORKFLOW:Test Secrets and Vars GITHUB_WORKSPACE:/workspace/digital/supBack ImageOS:ubuntu20 JOB_CONTAINER_NAME:GITEA-ACTIONS-TASK-297_WORKFLOW-Test-Secrets-and-Vars_JOB-build RUNNER_PERFLOG:/dev/null RUNNER_TRACKING_ID:]
2024-04-09T08:33:36.7225739Z evaluating expression ''
2024-04-09T08:33:36.7226320Z expression '' evaluated to 'true'
2024-04-09T08:33:36.7226477Z ⭐ Run Main Print secret and var
2024-04-09T08:33:36.7226699Z Writing entry to tarball workflow/outputcmd.txt len:0
2024-04-09T08:33:36.7226885Z Writing entry to tarball workflow/statecmd.txt len:0
2024-04-09T08:33:36.7227024Z Writing entry to tarball workflow/pathcmd.txt len:0
2024-04-09T08:33:36.7227160Z Writing entry to tarball workflow/envs.txt len:0
2024-04-09T08:33:36.7227263Z Writing entry to tarball workflow/SUMMARY.md len:0
2024-04-09T08:33:36.7227390Z Extracting content to '/var/run/act'
2024-04-09T08:33:36.7598506Z expression 'echo "Username var: ${{ vars.USERNAME_VARIABLE }}"\necho "Username secret: ${{ secrets.USERNAME_SECRET }}"' rewritten to 'format('echo "Username var: {0}"\necho "Username secret: {1}"', vars.USERNAME_VARIABLE, secrets.USERNAME_SECRET)'
2024-04-09T08:33:36.7598902Z evaluating expression 'format('echo "Username var: {0}"\necho "Username secret: {1}"', vars.USERNAME_VARIABLE, secrets.USERNAME_SECRET)'
2024-04-09T08:33:36.7599367Z expression 'format('echo "Username var: {0}"\necho "Username secret: {1}"', vars.USERNAME_VARIABLE, secrets.USERNAME_SECRET)' evaluated to '%!t(string=echo "Username var: tester"\necho "Username secret: ")'
2024-04-09T08:33:36.7599498Z Wrote command \n\necho "Username var: tester"\necho "Username secret: "\n\n to 'workflow/0.sh'
2024-04-09T08:33:36.7599696Z Writing entry to tarball workflow/0.sh len:54
2024-04-09T08:33:36.7599905Z Extracting content to '/var/run/act'
2024-04-09T08:33:36.7626815Z   🐳  docker exec cmd=[sh -e /var/run/act/workflow/0.sh] user= workdir=
2024-04-09T08:33:36.7627145Z Exec command '[sh -e /var/run/act/workflow/0.sh]'
2024-04-09T08:33:36.7627518Z Working directory '/workspace/digital/supBack'
2024-04-09T08:33:36.8295547Z Username var: tester
2024-04-09T08:33:36.8296062Z Username secret: 
2024-04-09T08:33:36.8451802Z Cleaning up services for job build
2024-04-09T08:33:36.8452363Z Cleaning up container for job build
2024-04-09T08:33:37.0474596Z Removed container: 669befa3a5a42b5e6bae1067779f191cb142dbe63abc6537ab0d51176d37a077
2024-04-09T08:33:37.0489031Z   🐳  docker volume rm GITEA-ACTIONS-TASK-297_WORKFLOW-Test-Secrets-and-Vars_JOB-build
2024-04-09T08:33:37.0519061Z   🐳  docker volume rm GITEA-ACTIONS-TASK-297_WORKFLOW-Test-Secrets-and-Vars_JOB-build-env
2024-04-09T08:33:37.0536361Z Cleaning up network for job build, and network name is: GITEA-ACTIONS-TASK-297_WORKFLOW-Test-Secrets-and-Vars_JOB-build-network
2024-04-09T08:33:37.1731766Z 🏁  Job succeeded

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

Originally created by @QuantumQuacken on GitHub (Apr 9, 2024). ### 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: ```yml name: Test Secrets and Vars on: push: branches: [main] jobs: build: runs-on: [ubuntu-latest] container: image: catthehacker/ubuntu:mod-hosts steps: - name: Print secret and var run: | echo "Username var: ${{ vars.USERNAME_VARIABLE }}" echo "Username secret: ${{ secrets.USERNAME_SECRET }}" ``` With a repository owned by an organization, with no variables or secrets on the ORG or REPO level, the output of the workflow is: ``` Username var: tester-user Username secret: ``` Same case, with the _USERNAME_SECRET_ set on the ORG, the output is: ``` Username var: tester-user Username secret: *** ``` 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? <details> <summary>Set up job of the workflow:</summary> ``` 2024-04-09T08:33:35.9732276Z testRunner(version:v0.2.6) received task 297 of job 316, be triggered by event: push 2024-04-09T08:33:35.9748040Z workflow prepared 2024-04-09T08:33:35.9750946Z evaluating expression 'success()' 2024-04-09T08:33:35.9753135Z expression 'success()' evaluated to 'true' 2024-04-09T08:33:35.9753595Z 🚀 Start image=catthehacker/ubuntu:mod-hosts 2024-04-09T08:33:35.9867221Z 🐳 docker pull image=catthehacker/ubuntu:mod-hosts platform= username= forcePull=false 2024-04-09T08:33:35.9867396Z 🐳 docker pull catthehacker/ubuntu:mod-hosts 2024-04-09T08:33:35.9887351Z Image exists? true 2024-04-09T08:33:36.0954194Z 🐳 docker create image=catthehacker/ubuntu:mod-hosts platform= entrypoint=["/bin/sleep" "10800"] cmd=[] 2024-04-09T08:33:36.1022365Z Common container.Config ==> &{Hostname: Domainname: User: AttachStdin:false AttachStdout:false AttachStderr:false ExposedPorts:map[] Tty:false OpenStdin:false StdinOnce:false Env:[RUNNER_TOOL_CACHE=/opt/hostedtoolcache RUNNER_OS=Linux RUNNER_ARCH=X64 RUNNER_TEMP=/tmp LANG=C.UTF-8] Cmd:[] Healthcheck:<nil> ArgsEscaped:false Image:catthehacker/ubuntu:mod-hosts Volumes:map[] WorkingDir:/workspace/digital/supBack Entrypoint:[] NetworkDisabled:false MacAddress: OnBuild:[] Labels:map[] StopSignal: StopTimeout:<nil> Shell:[]} 2024-04-09T08:33:36.1137538Z Common container.HostConfig ==> &{Binds:[/var/run/docker.sock:/var/run/docker.sock] ContainerIDFile: LogConfig:{Type: Config:map[]} NetworkMode:GITEA-ACTIONS-TASK-297_WORKFLOW-Test-Secrets-and-Vars_JOB-build-network PortBindings:map[] RestartPolicy:{Name: MaximumRetryCount:0} AutoRemove:true VolumeDriver: VolumesFrom:[] ConsoleSize:[0 0] Annotations:map[] CapAdd:[] CapDrop:[] CgroupnsMode: DNS:[] DNSOptions:[] DNSSearch:[] ExtraHosts:[] GroupAdd:[] IpcMode: Cgroup: Links:[] OomScoreAdj:0 PidMode: Privileged:false PublishAllPorts:false ReadonlyRootfs:false SecurityOpt:[] StorageOpt:map[] Tmpfs:map[] UTSMode: UsernsMode: ShmSize:0 Sysctls:map[] Runtime: Isolation: Resources:{CPUShares:0 Memory:0 NanoCPUs:0 CgroupParent: BlkioWeight:0 BlkioWeightDevice:[] BlkioDeviceReadBps:[] BlkioDeviceWriteBps:[] BlkioDeviceReadIOps:[] BlkioDeviceWriteIOps:[] CPUPeriod:0 CPUQuota:0 CPURealtimePeriod:0 CPURealtimeRuntime:0 CpusetCpus: CpusetMems: Devices:[] DeviceCgroupRules:[] DeviceRequests:[] KernelMemory:0 KernelMemoryTCP:0 MemoryReservation:0 MemorySwap:0 MemorySwappiness:<nil> OomKillDisable:<nil> PidsLimit:<nil> Ulimits:[] CPUCount:0 CPUPercent:0 IOMaximumIOps:0 IOMaximumBandwidth:0} Mounts:[{Type:volume Source:GITEA-ACTIONS-TASK-297_WORKFLOW-Test-Secrets-and-Vars_JOB-build Target:/workspace/digital/supBack ReadOnly:false Consistency: BindOptions:<nil> VolumeOptions:<nil> TmpfsOptions:<nil> ClusterOptions:<nil>} {Type:volume Source:act-toolcache Target:/toolcache ReadOnly:false Consistency: BindOptions:<nil> VolumeOptions:<nil> TmpfsOptions:<nil> ClusterOptions:<nil>} {Type:volume Source:GITEA-ACTIONS-TASK-297_WORKFLOW-Test-Secrets-and-Vars_JOB-build-env Target:/var/run/act ReadOnly:false Consistency: BindOptions:<nil> VolumeOptions:<nil> TmpfsOptions:<nil> ClusterOptions:<nil>}] MaskedPaths:[] ReadonlyPaths:[] Init:<nil>} 2024-04-09T08:33:36.2710536Z Created container name=GITEA-ACTIONS-TASK-297_WORKFLOW-Test-Secrets-and-Vars_JOB-build id=669befa3a5a42b5e6bae1067779f191cb142dbe63abc6537ab0d51176d37a077 from image catthehacker/ubuntu:mod-hosts (platform: ) 2024-04-09T08:33:36.2710950Z ENV ==> [RUNNER_TOOL_CACHE=/opt/hostedtoolcache RUNNER_OS=Linux RUNNER_ARCH=X64 RUNNER_TEMP=/tmp LANG=C.UTF-8] 2024-04-09T08:33:36.2711117Z 🐳 docker run image=catthehacker/ubuntu:mod-hosts platform= entrypoint=["/bin/sleep" "10800"] cmd=[] 2024-04-09T08:33:36.2711229Z Starting container: 669befa3a5a42b5e6bae1067779f191cb142dbe63abc6537ab0d51176d37a077 2024-04-09T08:33:36.5270495Z Started container: 669befa3a5a42b5e6bae1067779f191cb142dbe63abc6537ab0d51176d37a077 2024-04-09T08:33:36.6712413Z Writing entry to tarball workflow/event.json len:4217 2024-04-09T08:33:36.6713296Z Writing entry to tarball workflow/envs.txt len:0 2024-04-09T08:33:36.6713569Z Extracting content to '/var/run/act/' 2024-04-09T08:33:36.7119767Z setupEnv => map[ACT:true ACTIONS_CACHE_URL:http://172.17.0.2:41349/ ACTIONS_RUNTIME_TOKEN:*** ACTIONS_RUNTIME_URL:http://REDACTED:3000/api/actions_pipeline/ A_TEST_ENV_NAME_1:a_test_env_value_1 A_TEST_ENV_NAME_2:a_test_env_value_2 CI:true GITEA_ACTIONS:true GITEA_ACTIONS_RUNNER_VERSION:v0.2.6 GITHUB_ACTION:0 GITHUB_ACTIONS:true GITHUB_ACTION_PATH: GITHUB_ACTION_REF: GITHUB_ACTION_REPOSITORY: GITHUB_ACTOR:tester GITHUB_API_URL:http://REDACTED:3000/api/v1 GITHUB_BASE_REF: GITHUB_EVENT_NAME:push GITHUB_EVENT_PATH:/var/run/act/workflow/event.json GITHUB_GRAPHQL_URL: GITHUB_HEAD_REF: GITHUB_JOB:build GITHUB_REF:refs/heads/main GITHUB_REF_NAME:main GITHUB_REF_TYPE:branch GITHUB_REPOSITORY:digital/supBack GITHUB_REPOSITORY_OWNER:digital GITHUB_RETENTION_DAYS: GITHUB_RUN_ID:219 GITHUB_RUN_NUMBER:25 GITHUB_SERVER_URL:http://REDACTED:3000 GITHUB_SHA:7b37b5765defe012936001b3b6e718e47248c01d GITHUB_TOKEN:*** GITHUB_WORKFLOW:Test Secrets and Vars GITHUB_WORKSPACE:/workspace/digital/supBack ImageOS:ubuntu20 JOB_CONTAINER_NAME:GITEA-ACTIONS-TASK-297_WORKFLOW-Test-Secrets-and-Vars_JOB-build RUNNER_PERFLOG:/dev/null RUNNER_TRACKING_ID:] 2024-04-09T08:33:36.7225739Z evaluating expression '' 2024-04-09T08:33:36.7226320Z expression '' evaluated to 'true' 2024-04-09T08:33:36.7226477Z ⭐ Run Main Print secret and var 2024-04-09T08:33:36.7226699Z Writing entry to tarball workflow/outputcmd.txt len:0 2024-04-09T08:33:36.7226885Z Writing entry to tarball workflow/statecmd.txt len:0 2024-04-09T08:33:36.7227024Z Writing entry to tarball workflow/pathcmd.txt len:0 2024-04-09T08:33:36.7227160Z Writing entry to tarball workflow/envs.txt len:0 2024-04-09T08:33:36.7227263Z Writing entry to tarball workflow/SUMMARY.md len:0 2024-04-09T08:33:36.7227390Z Extracting content to '/var/run/act' 2024-04-09T08:33:36.7598506Z expression 'echo "Username var: ${{ vars.USERNAME_VARIABLE }}"\necho "Username secret: ${{ secrets.USERNAME_SECRET }}"' rewritten to 'format('echo "Username var: {0}"\necho "Username secret: {1}"', vars.USERNAME_VARIABLE, secrets.USERNAME_SECRET)' 2024-04-09T08:33:36.7598902Z evaluating expression 'format('echo "Username var: {0}"\necho "Username secret: {1}"', vars.USERNAME_VARIABLE, secrets.USERNAME_SECRET)' 2024-04-09T08:33:36.7599367Z expression 'format('echo "Username var: {0}"\necho "Username secret: {1}"', vars.USERNAME_VARIABLE, secrets.USERNAME_SECRET)' evaluated to '%!t(string=echo "Username var: tester"\necho "Username secret: ")' 2024-04-09T08:33:36.7599498Z Wrote command \n\necho "Username var: tester"\necho "Username secret: "\n\n to 'workflow/0.sh' 2024-04-09T08:33:36.7599696Z Writing entry to tarball workflow/0.sh len:54 2024-04-09T08:33:36.7599905Z Extracting content to '/var/run/act' 2024-04-09T08:33:36.7626815Z 🐳 docker exec cmd=[sh -e /var/run/act/workflow/0.sh] user= workdir= 2024-04-09T08:33:36.7627145Z Exec command '[sh -e /var/run/act/workflow/0.sh]' 2024-04-09T08:33:36.7627518Z Working directory '/workspace/digital/supBack' 2024-04-09T08:33:36.8295547Z Username var: tester 2024-04-09T08:33:36.8296062Z Username secret: 2024-04-09T08:33:36.8451802Z Cleaning up services for job build 2024-04-09T08:33:36.8452363Z Cleaning up container for job build 2024-04-09T08:33:37.0474596Z Removed container: 669befa3a5a42b5e6bae1067779f191cb142dbe63abc6537ab0d51176d37a077 2024-04-09T08:33:37.0489031Z 🐳 docker volume rm GITEA-ACTIONS-TASK-297_WORKFLOW-Test-Secrets-and-Vars_JOB-build 2024-04-09T08:33:37.0519061Z 🐳 docker volume rm GITEA-ACTIONS-TASK-297_WORKFLOW-Test-Secrets-and-Vars_JOB-build-env 2024-04-09T08:33:37.0536361Z Cleaning up network for job build, and network name is: GITEA-ACTIONS-TASK-297_WORKFLOW-Test-Secrets-and-Vars_JOB-build-network 2024-04-09T08:33:37.1731766Z 🏁 Job succeeded ``` </details> 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](https://docs.gitea.com/installation/install-from-binary) and set it up as a service as described [here](https://docs.gitea.com/installation/linux-service). I'm using act-runner v0.2.6 in Docker 26.0.0 build 2ae903e. ### Database PostgreSQL
GiteaMirror added the topic/gitea-actionstype/bug labels 2025-11-02 10:21:32 -06:00
GiteaMirror commented 2025-11-02 10:21:33 -06:00
Author
Owner
Copy Link

@wolfogre commented on GitHub (Apr 10, 2024):

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.

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.
It is designed that a repo can only read variables and secrets from its own and its owner (user or org).

So what surprised me is:

... 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 ...
With a repository owned by an organization, with no variables or secrets on the ORG or REPO level, the output of the workflow is:

Username var: tester-user
Username secret:

It shouldn't be, and I tried to reproduce it in my local environment. Please point out which step should be adjusted.

  1. Log in with the user "root".
  2. Create a repo for the org "test_org".
  3. Set a variable "USERNAME_VARIABLE" for the user "root".
  4. Run actions for the repo.
image

This is as expected.

@wolfogre commented on GitHub (Apr 10, 2024): > 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. 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. It is designed that a repo can only read variables and secrets from its own and its owner (user or org). So what surprised me is: > ... 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 ... > With a repository owned by an organization, with no variables or secrets on the ORG or REPO level, the output of the workflow is: > ``` > Username var: tester-user > Username secret: > ``` It shouldn't be, and I tried to reproduce it in my local environment. Please point out which step should be adjusted. 1. Log in with the user "root". 2. Create a repo for the org "test_org". 3. Set a variable "USERNAME_VARIABLE" for the user "root". 4. Run actions for the repo. <img width="906" alt="image" src="https://github.com/go-gitea/gitea/assets/9418365/a8ab22a7-fef3-478c-82d5-cc897d03c300"> This is as expected.
GiteaMirror commented 2025-11-02 10:21:34 -06:00
Author
Owner
Copy Link

@QuantumQuacken commented on GitHub (Apr 10, 2024):

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.
It is designed that a repo can only read variables and secrets from its own and its owner (user or org).

Thank you for the clarification.
Sorry for going slightly OT: is there a way to use the actor's variables and secrets in this scenario (repo owned by org)? Can they somehow be securely injected into the workflow?

It shouldn't be, and I tried to reproduce it in my local environment. Please point out which step should be adjusted.

I'd say the steps are correct. I tried reproducing it again, and I got the same output (see screenshot).

image

My steps:

  1. Logged in with my root user, set a variable "USERNAME_VARIABLE" to "tester-user".
  2. With my root user I created a new org "test_org".
  3. Under that org I created a repo "test_repo" and added the .yaml file (same as the one in the orginal post).
  4. Run action.

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.

image

Let me know what I can share to dig deeper into the issue.

@QuantumQuacken commented on GitHub (Apr 10, 2024): > 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. It is designed that a repo can only read variables and secrets from its own and its owner (user or org). Thank you for the clarification. Sorry for going slightly OT: is there a way to use the actor's variables and secrets in this scenario (repo owned by org)? Can they somehow be securely injected into the workflow? > It shouldn't be, and I tried to reproduce it in my local environment. Please point out which step should be adjusted. I'd say the steps are correct. I tried reproducing it again, and I got the same output (see screenshot). ![image](https://github.com/go-gitea/gitea/assets/10146689/2aba6642-a391-43e8-a03e-30fea062aae8) My steps: 1. Logged in with my root user, set a variable "USERNAME_VARIABLE" to "tester-user". 2. With my root user I created a new org "test_org". 3. Under that org I created a repo "test_repo" and added the .yaml file (same as the one in the orginal post). 4. Run action. 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. ![image](https://github.com/go-gitea/gitea/assets/10146689/5a1b6cd2-0574-478f-ae09-e02c47f22f15) Let me know what I can share to dig deeper into the issue.
GiteaMirror commented 2025-11-02 10:21:34 -06:00
Author
Owner
Copy Link

@wolfogre commented on GitHub (Apr 10, 2024):

is there a way to use the actor's variables and secrets in this scenario (repo owned by org)? Can they somehow be securely injected into the workflow?

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. 😄

I tried reproducing it again, and I got the same output (see screenshot).

Could you please check:

  • /test_org/test_repo/settings/actions/variables, is there any variable for the repo?
  • /org/test_org/settings/actions/variables, is there any variable for the org?
  • /admin/actions/variables, is there any variable for the whole Gitea instance? (I almost forgot it since it was just recently supported)
@wolfogre commented on GitHub (Apr 10, 2024): > is there a way to use the actor's variables and secrets in this scenario (repo owned by org)? Can they somehow be securely injected into the workflow? 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. 😄 > I tried reproducing it again, and I got the same output (see screenshot). Could you please check: - `/test_org/test_repo/settings/actions/variables`, is there any variable for the repo? - `/org/test_org/settings/actions/variables`, is there any variable for the org? - `/admin/actions/variables`, is there any variable for the whole Gitea instance? (I almost forgot it since it was just recently supported)
GiteaMirror commented 2025-11-02 10:21:34 -06:00
Author
Owner
Copy Link

@QuantumQuacken commented on GitHub (Apr 10, 2024):

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. 😄

It's a new topic for me, so thank you very much for the explanation!

test_repo variables:
chrome_xDM02XhxxK

test_org variables:
chrome_XzXMnfp7gi

I can't see any variables section in the Admin settings. Was it added in 1.22 or later?
chrome_ai28UMkd5g

@QuantumQuacken commented on GitHub (Apr 10, 2024): > 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. 😄 It's a new topic for me, so thank you very much for the explanation! test_repo variables: ![chrome_xDM02XhxxK](https://github.com/go-gitea/gitea/assets/10146689/c88b5dc9-bc3d-4fbf-b951-401764ae0c61) test_org variables: ![chrome_XzXMnfp7gi](https://github.com/go-gitea/gitea/assets/10146689/d0e4b063-e602-48ab-a1e8-0105407c00fe) I can't see any variables section in the Admin settings. Was it added in 1.22 or later? ![chrome_ai28UMkd5g](https://github.com/go-gitea/gitea/assets/10146689/6ef2fe63-d0f3-4aed-b73f-39048e6429f7)
GiteaMirror commented 2025-11-02 10:21:34 -06:00
Author
Owner
Copy Link

@wolfogre commented on GitHub (Apr 11, 2024):

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.

@wolfogre commented on GitHub (Apr 11, 2024): > 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.
GiteaMirror commented 2025-11-02 10:21:34 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Apr 11, 2024):

Closed by #30402

@lunny commented on GitHub (Apr 11, 2024): Closed by #30402
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label topic/gitea-actions type/bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#12805
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?