跳到主要内容

Using Variables and Secrets

Applicable Scenarios: When you need to use environment variables, configuration variables, secrets, or input parameters in a workflow and understand their scope and priority rules.

Prerequisites

  • Required vars and secrets have been created in the AtomGit interface (Path: Project Settings → Action Secrets and Variables).
  • Understand the differences between env, vars, secrets, and inputs.

Quick Example

name: ci-with-vars

on:
push:
branches:
- main
workflow_dispatch:
inputs:
environment:
description: "Deployment environment"
type: string
default: test

env:
APP_NAME: demo-app

jobs:
build:
runs-on: [ubuntu-latest, x64, small]
env:
BUILD_MODE: release
steps:
- uses: checkout

- name: Print variables
env:
STEP_VAR: step-level
run: |
echo "APP_NAME=$APP_NAME"
echo "BUILD_MODE=$BUILD_MODE"
echo "STEP_VAR=$STEP_VAR"
echo "CONFIG_VAR=${{ vars.DEPLOY_TARGET }}"
echo "SHA=${{ atomgit.sha }}"

- name: Use secret
env:
REGISTRY_PASSWORD: ${{ secrets.REGISTRY_PASSWORD }}
run: echo "password is masked"

Configuration Explanation

Four Types of Variables

TypeSuitable for storingSensitiveDefined locationReference method
envTemporary environment variables within the workflowNoYAML file$APP_NAME or ${{ env.APP_NAME }}
varsGeneral configuration at repository/organization levelNoAtomGit interface${{ vars.DEPLOY_TARGET }}
secretsPasswords, tokens, private keysYesAtomGit interface${{ secrets.REGISTRY_PASSWORD }}
inputsInputs for workflow_dispatch / workflow_callNoYAML file${{ inputs.environment }}

env Environment Variables

env supports three levels of scope: Workflow level → Job level → Step level

env:
APP_NAME: demo-app # Workflow level, visible to all jobs and steps

jobs:
build:
env:
BUILD_MODE: release # Job level, visible to all steps within this job
steps:
- env:
STEP_VAR: step-level # Step level, visible only to this step
run: echo "$STEP_VAR"

Priority Rules: Step level > Job level > Workflow level. A step-level variable with the same name will override the job-level and workflow-level variables.

YAML reference vs Runner reference:

Reference methodSyntaxApplicable scenario
YAML reference (expression)${{ env.APP_NAME }}Used in YAML fields, replaced before the runner executes
Runner reference (environment variable)$APP_NAMEUsed in run commands, interpreted by the shell

vars Configuration Variables

vars are created in the AtomGit interface and support repository-level and organization-level scope:

steps:
- name: Use config variable
run: echo "deploy to ${{ vars.DEPLOY_TARGET }}"

Creation path: Repository settings → Variables → New variable

Secrets

secrets are encrypted and created in the AtomGit interface, automatically masked as *** in logs:

steps:
- name: Login registry
env:
REGISTRY_USERNAME: ${{ secrets.REGISTRY_USERNAME }}
REGISTRY_PASSWORD: ${{ secrets.REGISTRY_PASSWORD }}
run: |
echo "$REGISTRY_PASSWORD" | docker login example.com -u "$REGISTRY_USERNAME" --password-stdin

Security Tip:

  • Do not print secrets in logs (logging echo "$SECRET" will mask it, but echo "${{ secrets.MY_SECRET }}" might bypass masking).
  • Do not write secrets into artifacts or caches.
  • High-privilege secrets should not be exposed by default for PR/MR from external contributors.

System Variables

AtomGit Action system variables use the ATOMGIT_* prefix:

System VariableDescription
ATOMGIT_TOKENAutomatically generated workflow token
ATOMGIT_SHACurrent commit SHA
ATOMGIT_REFCurrent branch or tag reference
ATOMGIT_EVENT_NAMETrigger event name
ATOMGIT_REPOSITORYRepository identifier (owner/repo)
ATOMGIT_WORKSPACEWorking directory on the runner
ATOMGIT_OUTPUTFile path where step output is written
ATOMGIT_ENVFile path where environment variables are written
ATOMGIT_PATHFile path where PATH is written
ATOMGIT_RUNNER_OSRunner operating system
ATOMGIT_RUNNER_ARCHRunner architecture

Overview of Priority Rules

From highest to lowest:

  1. Step-level env
  2. Job-level env
  3. Workflow-level env
  4. vars (configuration variables)
  5. System variables (ATOMGIT_*)