gitea/gitea-docs
1
0
Fork 0
mirror of https://gitea.com/gitea/docs.git synced 2026-06-11 12:41:27 +00:00
Code Issues Packages Projects Releases Wiki Activity

Add note about how to use secrets in workflow (#17)

Browse Source 
Document how to use secrets in workflow

Co-authored-by: Jerry Jacobs <jerry.jacobs@xor-gate.org>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Reviewed-on: https://gitea.com/gitea/docs/pulls/17
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: xor-gate <xor-gate@noreply.gitea.com>
Co-committed-by: xor-gate <xor-gate@noreply.gitea.com>
This commit is contained in:
xor-gate
2024-07-12 15:25:32 +00:00
committed by techknowlogick
parent 26f2306525
commit c94a135d4a
5 changed files with 40 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
docs/usage/actions/secrets.md
View File

@@ -1,5 +1,5 @@
---
date: "2022-12-19T21:26:00+08:00"
date: "2024-07-10T09:23:00+02:00"
slug: "secrets"
sidebar_position: 50
---
@@ -25,4 +25,11 @@ The following rules apply to secret names:
For example, a secret created at the repository level must have a unique name in that repository, and a secret created at the organization level must have a unique name at that level.
### Using secrets
After creating configuration variables, they will be automatically filled in the `secrets` context.
They can be accessed through expressions like `${{ secrets.SECRET_NAME }}` in the workflow.
### Precedence
If a secret with the same name exists at multiple levels, the secret at the lowest level takes precedence. For example, if an organization-level secret has the same name as a repository-level secret, then the repository-level secret takes precedence.

9
versioned_docs/version-1.19/usage/secrets.md
View File

@@ -1,5 +1,5 @@
---
date: "2022-12-19T21:26:00+08:00"
date: "2024-07-10T09:23:00+02:00"
title: "Secrets"
slug: "usage/secrets"
sidebar_position: 50
@@ -34,4 +34,11 @@ The following rules apply to secret names:
For example, a secret created at the repository level must have a unique name in that repository, and a secret created at the organization level must have a unique name at that level.
### Using secrets
After creating configuration variables, they will be automatically filled in the `secrets` context.
They can be accessed through expressions like `${{ secrets.SECRET_NAME }}` in the workflow.
### Precedence
If a secret with the same name exists at multiple levels, the secret at the lowest level takes precedence. For example, if an organization-level secret has the same name as a repository-level secret, then the repository-level secret takes precedence.

9
versioned_docs/version-1.20/usage/secrets.md
View File

@@ -1,5 +1,5 @@
---
date: "2022-12-19T21:26:00+08:00"
date: "2024-07-10T09:23:00+02:00"
title: "Secrets"
slug: "secrets"
sidebar_position: 50
@@ -36,4 +36,11 @@ The following rules apply to secret names:
For example, a secret created at the repository level must have a unique name in that repository, and a secret created at the organization level must have a unique name at that level.
### Using secrets
After creating configuration variables, they will be automatically filled in the `secrets` context.
They can be accessed through expressions like `${{ secrets.SECRET_NAME }}` in the workflow.
### Precedence
If a secret with the same name exists at multiple levels, the secret at the lowest level takes precedence. For example, if an organization-level secret has the same name as a repository-level secret, then the repository-level secret takes precedence.

9
versioned_docs/version-1.21/usage/secrets.md
View File

@@ -1,5 +1,5 @@
---
date: "2022-12-19T21:26:00+08:00"
date: "2024-07-10T09:23:00+02:00"
title: "Secrets"
slug: "secrets"
sidebar_position: 50
@@ -36,4 +36,11 @@ The following rules apply to secret names:
For example, a secret created at the repository level must have a unique name in that repository, and a secret created at the organization level must have a unique name at that level.
### Using secrets
After creating configuration variables, they will be automatically filled in the `secrets` context.
They can be accessed through expressions like `${{ secrets.SECRET_NAME }}` in the workflow.
### Precedence
If a secret with the same name exists at multiple levels, the secret at the lowest level takes precedence. For example, if an organization-level secret has the same name as a repository-level secret, then the repository-level secret takes precedence.

9
versioned_docs/version-1.22/usage/actions/secrets.md
View File

@@ -1,5 +1,5 @@
---
date: "2022-12-19T21:26:00+08:00"
date: "2024-07-10T09:23:00+02:00"
slug: "secrets"
sidebar_position: 50
---
@@ -25,4 +25,11 @@ The following rules apply to secret names:
For example, a secret created at the repository level must have a unique name in that repository, and a secret created at the organization level must have a unique name at that level.
### Using secrets
After creating configuration variables, they will be automatically filled in the `secrets` context.
They can be accessed through expressions like `${{ secrets.SECRET_NAME }}` in the workflow.
### Precedence
If a secret with the same name exists at multiple levels, the secret at the lowest level takes precedence. For example, if an organization-level secret has the same name as a repository-level secret, then the repository-level secret takes precedence.