Context

Defines the context available in the AtomGit Pipeline workflow, including available properties, access methods, and usage examples.

2.1 Available Contexts

Context Name	Type	Description
atomgit	object	Information about the workflow run. For more information, see atomgit.
env	object	Variables set in the workflow, job, or step. For more information, see env.
vars	object	Variables set at the repository, organization, or environment level. For more information, see vars.
job	object	Information about the currently running job. For more information, see job.
jobs	object	For reusable workflows only, contains outputs from the reusable workflow. For more information, see jobs.
steps	object	Information about steps that have run in the current job. For more information, see steps.
runner	object	Information about the execution environment running the current job. For more information, see runner.
secrets	object	Names and values of secrets available for the workflow run. For more information, see secret.
strategy	object	Information about the matrix execution strategy for the current job. For more information, see strategy.
matrix	object	Matrix properties defined in the workflow applicable to the current job. For more information, see matrix.
inputs	object	Input properties passed to an action, reusable workflow, or manually triggered workflow. For more information, see inputs.

You can access context information using one of the following two syntaxes as part of an expression.

• Index syntax: atomgit['sha']
• Property dereference syntax: atomgit.sha To use property dereference syntax, the property name must start with a letter or _, and can only contain alphanumeric characters, -, or _.

If you try to reference a non-existent property, it will evaluate to an empty string.

Determining When to Use Context

• Default environment variables: These environment variables exist only on the execution environment where your job runs.
• Context: You can use most contexts at any time in the workflow, including when default variables are not available. For example, you can use context with expressions to perform initial processing before the task is sent to the execution environment; this allows you to use context related to the if keyword to determine whether a step should be run. Once the job starts running, you can also retrieve context variables from the execution environment where the job is running, such as runner.os. The following example demonstrates how to use these different types of variables together in a job:

name: CI
on:
  push:
    branches: main
jobs:
  prod-check:
    if: ${{ atomgit.ref == 'refs/heads/main' }}
    runs-on: ubuntu-latest
    steps:
      - name: Run echo
        run: echo "Deploying to production server on branch $ATOMGIT_REF"

In this example, the if statement checks the context to determine the current branch name; if the name is refs/heads/main, the subsequent steps are executed. The if check is handled by AtomGit Pipeline, and the task is only sent to the execution environment if the result is true. Once the task is sent to the execution environment, the steps are executed and refer to variables from the environment.

Context Availability

Different contexts are available at different times during a workflow run. For example, the secrets context may only be available in certain parts of a job.

Additionally, some functions may only be available in certain places. For example, the hashFiles function is not available everywhere.

The following table lists the usage restrictions for each context and special function in the workflow. The listed contexts are only available for the given workflow keys and cannot be used elsewhere. Unless listed below, functions can be used anywhere.

Workflow Scenario	Available Contexts	Special Functions
run-name	atomgit, inputs, vars	None
concurrency	atomgit, inputs, vars	None
env	atomgit, secrets, inputs, vars	None
jobs.<job_id>.concurrency	atomgit, strategy, matrix, inputs, vars	None
jobs.<job_id>.container	atomgit, strategy, matrix, vars, inputs	None
jobs.<job_id>.container.credentials	atomgit, strategy, matrix, env, vars, secrets, inputs	None
jobs.<job_id>.container.env.<env_id>	atomgit, strategy, matrix, job, runner, env, vars, secrets, inputs	None
jobs.<job_id>.container.image	atomgit, strategy, matrix, vars, inputs	None
jobs.<job_id>.continue-on-error	atomgit, strategy, matrix, vars, inputs	None
jobs.<job_id>.defaults.run	atomgit, strategy, matrix, env, vars, inputs	None
jobs.<job_id>.env	atomgit, strategy, matrix, vars, secrets, inputs	None
jobs.<job_id>.if	atomgit, vars, inputs	always, cancelled, success, failure
jobs.<job_id>.name	atomgit, strategy, matrix, vars, inputs	None
jobs.<job_id>.outputs.<output_id>	atomgit, strategy, matrix, job, runner, env, vars, secrets, steps, inputs	None
jobs.<job_id>.runs-on	atomgit, strategy, matrix, vars, inputs	None
jobs.<job_id>.secrets.<secrets_id>	atomgit, strategy, matrix, secrets, inputs, vars	None
jobs.<job_id>.steps.continue-on-error	atomgit, strategy, matrix, job, runner, env, vars, secrets, steps, inputs	hashFiles
jobs.<job_id>.steps.env	atomgit, strategy, matrix, job, runner, env, vars, secrets, steps, inputs	hashFiles
jobs.<job_id>.steps.if	atomgit, strategy, matrix, job, runner, env, vars, steps, inputs	always, cancelled, success, failure, hashFiles
jobs.<job_id>.steps.name	atomgit, strategy, matrix, job, runner, env, vars, secrets, steps, inputs	hashFiles
jobs.<job_id>.steps.run	atomgit, strategy, matrix, job, runner, env, vars, secrets, steps, inputs	hashFiles
jobs.<job_id>.steps.timeout-minutes	atomgit, strategy, matrix, job, runner, env, vars, secrets, steps, inputs	hashFiles
jobs.<job_id>.steps.with	atomgit, strategy, matrix, job, runner, env, vars, secrets, steps, inputs	hashFiles
jobs.<job_id>.steps.working-directory	atomgit, strategy, matrix, job, runner, env, vars, secrets, steps, inputs	hashFiles
jobs.<job_id>.strategy	atomgit, vars, inputs	None
jobs.<job_id>.timeout-minutes	atomgit, strategy, matrix, vars, inputs	None
jobs.<job_id>.with.<with_id>	atomgit, strategy, matrix, inputs, vars	None
on.workflow_call.inputs.<inputs_id>.default	atomgit, inputs, vars	None
on.workflow_call.outputs.<output_id>.value	atomgit, jobs, vars, inputs	None

Example: Print Context Information to Log

You can print the contents of the context to the log for debugging. It is necessary to pretty-print the JSON object to the log.

[!WARNING] When using the entire atomgit context, be aware that it contains sensitive information such as atomgit.token. AtomGit Pipeline will mask them when printing keys to the console, but you should be cautious when exporting or printing the context.

name: Context testing

on:
  push:
    branches: main

jobs:

dump_contexts_to_log:

  runs-on: ubuntu-latest

  steps:

    - name: Dump Atomgit context

      env:

        ATOMGIT_CONTEXT: ${{ toJson(atomgit) }}

      run: echo "$ATOMGIT_CONTEXT"

    - name: Dump job context

      env:

        JOB_CONTEXT: ${{ toJson(job) }}

      run: echo "$JOB_CONTEXT"

    - name: Dump steps context

      env:

        STEPS_CONTEXT: ${{ toJson(steps) }}

      run: echo "$STEPS_CONTEXT"

    - name: Dump runner context

      env:

        RUNNER_CONTEXT: ${{ toJson(runner) }}

      run: echo "$RUNNER_CONTEXT"

    - name: Dump strategy context

      env:

        STRATEGY_CONTEXT: ${{ toJson(strategy) }}

      run: echo "$STRATEGY_CONTEXT"

    - name: Dump matrix context

      env:

        MATRIX_CONTEXT: ${{ toJson(matrix) }}

      run: echo "$MATRIX_CONTEXT"

2.2 atomgit Context

The atomgit context contains information about the workflow run and the event that triggered the run. Most of the atomgit context data can be read in environment variables.

[!WARNING] When using the entire atomgit context, be aware that it contains sensitive information such as atomgit.token. AtomGit Pipeline will mask them when printing keys to the console, but you should be cautious when exporting or printing the context. [!WARNING] When creating workflows and actions, you should always consider whether your code might execute untrusted input from potential attackers. Some contexts should be considered untrusted input because attackers might insert their own malicious content.

Property Name	Type	Description
atomgit	object	The top-level context available during any job or step in the workflow. This object contains all the properties listed below.
atomgit.action	string	The name of the current action being run, or the step's name. AtomGit Pipeline removes special characters, and uses the name __run when a step runs without an id. If the same action is used multiple times in the same job, the name will include a suffix with an underscore sequence number. For example, the first script will be named __run, and the second script will be named __run_2. Similarly, the second call to actions/checkout will be actionscheckout2.
atomgit.action_path	string	The path where the action is located. This property is supported only in composite actions. You can use this path to access files in the same repository as the action, for example by changing directory to the path: cd ${{ atomgit.action_path }}.
atomgit.action_ref	string	For the step that executes the action, this is the reference of the action being executed. For example, v2. Do not use this in the run keyword. To make this context work with composite actions, reference it in the env context of the composite action.
atomgit.action_repository	string	For the step that executes the action, this is the owner and repository name of the action. For example, actions/checkout. Do not use this in the run keyword. To make this context work with composite actions, reference it in the env context of the composite action.
atomgit.actor	string	The username of the user who triggered the initial workflow run. If the workflow run is a re-run, this value may differ from atomgit.triggering_actor. Any workflow re-run will use the permissions of atomgit.actor, even if the participant who initiated the re-run (atomgit.triggering_actor) has different permissions.
atomgit.actor_id	string	The account ID of the person or application that triggered the initial workflow run. For example, 1234567. Note that this is different from the participant's username.
atomgit.api_url	string	The URL of the AtomGit REST API.
atomgit.base_ref	string	The base_ref or target branch of the pull request in the workflow run. This property is available only when the event that triggered the workflow run is pull_request or pull_request_target.
atomgit.env	string	The path to the file where environment variables are set from workflow commands on the execution environment. This file is unique to the current step, and each step in the job is a different file.
atomgit.event	object	The full event webhook payload. You can use this context to access individual properties of the event. This object is the same as the webhook payload of the event that triggered the workflow run, and varies for each event. The webhooks links for each AtomGit Pipeline event are in . For example, for a workflow run triggered by , this object contains the content of .
atomgit.event_name	string	The name of the event that triggered the workflow run.
atomgit.event_path	string	The path to the file on the execution environment containing the full event webhook payload.
atomgit.head_ref	string	The head_ref or source branch of the pull request in the workflow run. This property is available only when the event that triggered the workflow run is pull_request or pull_request_target.
atomgit.job	string	The ID of the current job. Note: This context property is set by the Actions execution environment and is only available within the steps of the job. Otherwise, the value of this property is null.
atomgit.path	string	The path to the file on the execution environment where the system PATH variable is set from workflow commands. This file is unique to the current step, and each step in the job is a different file.
atomgit.ref	string	The full reference of the branch or tag that triggered the workflow run. For a push triggered workflow, this is the pushed branch or tag reference. For an unmerged pull_request triggered workflow, this is the merge branch of the pull request. If the pull request has been merged, this is the main branch. For a release triggered workflow, this is the created release tag. For other triggers, this is the branch or tag reference that triggered the workflow run. This reference is set only when the event type has an available branch or tag. The given reference is full, meaning for branches, the format is refs/heads/<branch_name>. For events other than pull_request_target unmerged pull requests, it is refs/pull/<pr_number>/merge. The pull_request_target event has the ref from the base branch. For tags, it is refs/tags/<tag_name>. For example, refs/heads/feature-branch-1.
atomgit.ref_name	string	The short reference name of the branch or tag that triggered the workflow run. This value matches the branch or tag name shown on AtomGit. For example, feature-branch-1. For unmerged pull requests, the format is <pr_number>/merge.
atomgit.ref_type	string	The type of reference that triggered the workflow run. Valid values are branch or tag.
atomgit.repository	string	The owner and repository name. For example, octocat/Hello-World.
atomgit.repository_id	string	The ID of the repository. For example, 123456789. Note that this is different from the repository name.
atomgit.	string	The Git URL of the repository. For example, git://atomgit.com/octocat/hello-world.git.
atomgit.retention_days	string	The number of days to retain workflow run logs and artifacts.
atomgit.run_id	string	A unique number for each workflow run in the repository. If you re-run a workflow run, this number does not change.
atomgit.run_number	string	A unique number for each run of a specific workflow in the repository. This number starts at 1 for the first run of the workflow and increments with each new run. If you re-run a workflow run, this number does not change.
atomgit.run_attempt	string	A unique number for each attempt of a specific workflow run in the repository. This number starts at 1 for the first attempt of the workflow run and increments with each re-run.
atomgit.server_url	string	The URL of the AtomGit server. For example: https://atomgit.com.
atomgit.sha	string	The commit SHA that triggered the workflow. The value of this commit SHA depends on the event that triggered the workflow. For example, ffac537e6cbbf934b08745a378932722df287a53.
atomgit.token	string	The token used to authenticate as the AtomGit App installed on your repository. This is functionally equivalent to the ATOMGIT_TOKEN secret. Note: This context property is set by the Actions execution environment and is only available within the steps of the job. Otherwise, the value of this property is null.
atomgit.triggering_actor	string	The username of the user who started the workflow run. If the workflow run is a re-run, this value may differ from atomgit.actor. Any workflow re-run will use the permissions of atomgit.actor, even if the participant who initiated the re-run (atomgit.triggering_actor) has different permissions.
atomgit.workflow	string	The name of the workflow. If the workflow file does not specify a name, the value of this property is the full path of the workflow file in the repository.
atomgit.workflow_ref	string	The reference path of the workflow. For example, octocat/hello-world/.atomgit/workflows/my-workflow.yml@refs/heads/my_branch.
atomgit.workflow_sha	string	The commit SHA of the workflow file.
atomgit.workspace	string	The default working directory for steps in the execution environment, and the default location of your repository when using the actions/checkout action.
atomgit.start_timestamp	string	The timestamp when the workflow started.

2.3 atomgit.event

Overview

atomgit.event is a child object under the atomgit context, carrying the event payload that triggered this workflow run. When an event triggers a workflow, the platform mounts the complete payload of that event under atomgit.event for the workflow to access via expressions.

atomgit.event is 100% isomorphic to the event's Webhook payload: field names, nested levels, and value meanings are exactly the same. Therefore, the payload structure you see in the Webhook documentation can be directly accessed in the workflow using the form atomgit.event.<field path>. For example, comment.body in the payload becomes atomgit.event.comment.body in the workflow.

The fields mounted under atomgit.event vary depending on the triggering event. All events share a set of common base fields (action, sender, repository, etc.), and each event then appends its own specific fields. This chapter explains each event scenario separately.

Notes:

• atomgit.event.action indicates the activity type of the event (such as created, edited), which is not the same field as the top-level context atomgit.action (current step identifier), please do not confuse them.
• Fields marked "only xxx" appear only under the corresponding activity type, and reading them in other activity types will return an empty value.
• Fields like head_commit, merged_at, review.body may be null under certain conditions, it is recommended to check for null before using them.
• The "Values" column of the table lists the complete set of enumeration values for enumeration-type fields; other fields are free-form.

Common Base Fields (Shared by All Events)

The following fields exist in atomgit.event for all events, and are not repeated in subsequent scenarios.

Access Path	Type	Values	Purpose Description
atomgit.event.action	string	Depends on the event, see each scenario	The activity type of the event; push event has no this field. Often used to distinguish actions in if conditions
atomgit.event.sender.id	integer	—	User ID who triggered this event
atomgit.event.sender.login	string	—	Triggerer login name, used to identify who triggered this run
atomgit.event.repository.id	integer	—	Repository ID
atomgit.event.repository.name	string	—	Repository name
atomgit.event.repository.full_name	string	—	Full name of the repository (owner/repo name), commonly used to assemble API addresses
atomgit.event.repository.default_branch	string	—	Default branch name of the repository
atomgit.event.repository.private	boolean	true / false	Whether it is a private repository, affecting Fork and credential policies

push Event

Triggered when code is pushed. This event has no action field, and the payload focuses on the reference and commit information of this push.

Access Path	Type	Values	Purpose Description
atomgit.event.ref	string	—	The full reference being pushed, such as refs/heads/main, often used as a branch filter
atomgit.event.before	string	—	The commit SHA pointed to by the reference before the push; it is all zeros for a new branch
atomgit.event.after	string	—	The commit SHA pointed to by the reference after the push;
atomgit.event.created	boolean	true / false	Whether this push is a new reference
atomgit.event.base_ref	string	—	The source reference for the new branch, otherwise null
atomgit.event.head_commit.id	string	—	The SHA of the latest commit after the push; it is null when the branch is deleted
atomgit.event.head_commit.message	string	—	The message of the latest commit after the push

pull_request Event

Triggered when an activity occurs in a Pull Request, including opening, closing, editing, synchronizing, assigning, adding/removing labels, etc.

Activity Types:

Value	Trigger Time
opened	PR is created
updated	PR title or description is edited
closed	PR is closed (whether merged is checked by the merged field)
reopened	Closed PR is reopened

Fields:

Access Path	Type	Values	Purpose Description
atomgit.event.number	integer	—	PR serial number, same as pull_request.number as a parallel redundant field
atomgit.event.pull_request.id	integer	—	PR ID
atomgit.event.pull_request.number	integer	—	PR serial number, the main key for writing comments and calling APIs
atomgit.event.pull_request.title	string	—	PR title
atomgit.event.pull_request.body	string	—	PR description
atomgit.event.pull_request.state	string	open / closed	PR status
atomgit.event.pull_request.draft	boolean	true / false	Whether it is a draft PR, drafts often skip CI
atomgit.event.pull_request.merged	boolean	true / false	Whether it is merged, combined with closed to determine "merged rather than just closed"
atomgit.event.pull_request.merged_at	string	—	Merge time, null if not merged
atomgit.event.pull_request.user.login	string	—	PR submitter login name
atomgit.event.pull_request.labels	array	—	Label list, can be used to route pipelines by label
atomgit.event.pull_request.head.ref	string	—	Source branch name
atomgit.event.pull_request.head.sha	string	—	Latest commit SHA of the source branch, used when explicitly checking out PR code
atomgit.event.pull_request.merge_commit_sha	string	—	PR scene pre-merged head commit
atomgit.event.pull_request.head.repo.full_name	string	—	Full name of the source repository; in fork scenarios, it differs from base, used to determine external PR
atomgit.event.pull_request.base.ref	string	—	Target branch name, often used as a branch filter
atomgit.event.pull_request.base.sha	string	—	Latest commit SHA of the target branch
atomgit.event.pull_request.base.repo.full_name	string	—	Full name of the target repository, i.e., the repository where the workflow is located
atomgit.event.pull_request.created_at	string	—	PR creation time
atomgit.event.pull_request.updated_at	string	—	PR last update time

issue_comment Event

Triggered when a comment is created, edited, or deleted in the issue's main comment section.

Activity Types: created (comment is posted), edited (comment is edited), deleted (comment is deleted).

Access Path	Type	Values	Purpose Description
atomgit.event.issue.id	integer	—	Issue ID
atomgit.event.issue.number	integer	—	Issue serial number, the main key for writing comments
atomgit.event.issue.title	string	—	Issue title
atomgit.event.issue.body	string	—	Issue body
atomgit.event.issue.state	string	open / closed	Issue status
atomgit.event.issue.user.login	string	—	Issue creator
atomgit.event.issue.labels	array	—	Issue label list
atomgit.event.comment.id	integer	—	Comment ID, the main key for writing or updating comments
atomgit.event.comment.body	string	—	Comment content, can be used to parse /deploy instructions
atomgit.event.comment.user.login	string	—	Comment author
atomgit.event.comment.author_association	string	OWNER / MEMBER / COLLABORATOR / CONTRIBUTOR / FIRST_TIME_CONTRIBUTOR / FIRST_TIMER / NONE	The relationship between the comment author and the repository, used as a basis for permission filtering
atomgit.event.comment.created_at	string	—	Comment creation time
atomgit.event.comment.updated_at	string	—	Comment last update time

When deleted, comment is a snapshot of the comment before deletion.

pull_request_comment Event

Triggered when a comment is created, edited, or deleted in the pull request's main comment section (Conversation tab). The structure is symmetric to issue_comment, with the carrier replaced from issue to pull_request.

Activity Types:

created, edited, deleted, with the same meaning as issue_comment.

Access Path	Type	Values	Purpose Description
atomgit.event.pull_request.number	integer	—	PR serial number of the comment
atomgit.event.pull_request.state	string	open / closed	PR status
atomgit.event.pull_request.user.login	string	—	PR submitter
atomgit.event.pull_request.head.ref	string	—	Source branch name
atomgit.event.pull_request.head.sha	string	—	Latest commit SHA of the source branch, used for checking out when the comment triggers a CI rerun
atomgit.event.pull_request.merge_commit_sha	string	—	PR scene pre-merged head commit
atomgit.event.pull_request.head.repo.full_name	string	—	Full name of the source repository, used to determine if it is an external Fork
atomgit.event.pull_request.base.ref	string	—	Target branch name, often used as a branch filter
atomgit.event.pull_request.base.repo.full_name	string	—	Full name of the target repository
atomgit.event.comment.id	integer	—	Comment ID
atomgit.event.comment.body	string	—	Comment content, can be used to parse instructions
atomgit.event.comment.user.login	string	—	Comment author
atomgit.event.comment.author_association	string	OWNER / MEMBER / COLLABORATOR / CONTRIBUTOR / FIRST_TIME_CONTRIBUTOR / FIRST_TIMER / NONE	The relationship between the comment author and the repository, used as a basis for permission filtering
atomgit.event.comment.created_at	string	—	Comment creation time
atomgit.event.comment.updated_at	string	—	Comment last update time

pull_request_review Event

Triggered when a pull request review is submitted, edited, or dismissed. A review consists of several inline comments, a review body, and a review status.

Activity Types:

Value	Trigger Time
submitted	Review is submitted
edited	Review body is edited
dismissed	Review is dismissed (record retained, not deleted)

Fields:

Access Path	Type	Values	Purpose Description
atomgit.event.pull_request.number	integer	—	PR number being reviewed
atomgit.event.pull_request.state	string	open / closed	PR status
atomgit.event.pull_request.head.ref	string	—	Source branch name
atomgit.event.pull_request.head.sha	string	—	Latest commit SHA of the source branch
atomgit.event.pull_request.base.ref	string	—	Target branch name, often used as a branch filter
atomgit.event.review.id	integer	—	Review ID
atomgit.event.review.state	string	approved / changes_requested / commented / dismissed	Review result, core filtering field
atomgit.event.review.commit_id	string	—	The source branch SHA of the PR when the review was submitted, locking the version being reviewed
atomgit.event.review.submitted_at	string	—	Review submission time

Usage Examples

# A comment containing a /deploy instruction, and the commentor is a member of the repository triggers deployment
on:
  pull_request_comment:
    types: [created]

jobs:
  deploy:
    if: >-
      contains(atomgit.event.comment.body, '/deploy') &&
      contains(fromJSON('["OWNER","MEMBER"]'), atomgit.event.comment.author_association)
    runs-on: ubuntu-latest
    steps:
      - name: Run sh
        run: |
          echo "PR #$NUMBER ($HEAD → $BASE) received deployment instruction"
        env:
          NUMBER: ${{ atomgit.event.pull_request.number }}
          HEAD:   ${{ atomgit.event.pull_request.head.ref }}
          BASE:   ${{ atomgit.event.pull_request.base.ref }}

# Run subsequent tasks after the PR review is approved
on:
  pull_request_review:
    types: [submitted]

jobs:
  on_approved:
    if: ${{ atomgit.event.review.state == 'approved' }}
    runs-on: ubuntu-latest
    steps:
      - name: Run echo
        run: echo "PR #${{ atomgit.event.pull_request.number }} has been reviewed"

2.4 Other Context Details

env Context

The env context contains variables that have been set in the workflow, job, or step. It does not include variables inherited by the execution environment process.

You can retrieve the values of variables stored in the env context and use these values in your workflow file. You can use the env context in any key in the workflow steps, except for the id and uses keys.

If you want to use the value of a variable inside the execution environment, use the normal method of the execution environment's operating system to read the environment variable.

Property Name	Type	Description
env	object	This context is different for each step in the job. You can access this context from any step in the job. This object contains the properties listed below.
env.<env_name>	string	The value of a specific environment variable.

Example Content of the env Context

The content of the env context is a mapping from variable names to their values. The content of the context may depend on its usage location in the workflow run. In this example, the env context contains two variables.

{
  "first_name": "Mona",
  "super_duper_var": "totally_awesome"
}

Example Usage of the env Context

This example workflow shows how to set env context variables at the workflow, job, and step levels. Then, use the ${{ env.VARIABLE-NAME }} syntax to retrieve variable values in various steps of the workflow.

When multiple environment variables with the same name are defined, AtomGit Pipeline uses the most specific variable. For example, an environment variable defined in a step will override the job and workflow environment variables with the same name when the step is executed. Environment variables defined for a job will override the workflow variables with the same name when the job is executed.

name: Hi Mascot
on:
  push:
    branches: main
env:
  mascot: Mona
  super_duper_var: totally_awesome

jobs:
  windows_job:
    runs-on: windows-latest
    steps:
      - name: Run echo Mona
        run: echo 'Hi ${{ env.mascot }}'  # Hi Mona
      - name: Run echo Octocat
        run: echo 'Hi ${{ env.mascot }}'  # Hi Octocat
        env:
          mascot: Octocat
  linux_job:
    runs-on: ubuntu-latest
    env:
      mascot: Tux
    steps:
      - name: Run echo Tux
        run: echo 'Hi ${{ env.mascot }}'  # Hi Tux

vars Context

The vars context contains custom configuration variables set at the organization, repository, and environment levels.

Example Content of the vars Context

The content of the vars context is a mapping from configuration variable names to their values.

{
  "mascot": "Mona"
}

Example Usage of the vars Context

This example workflow shows how configuration variables set at the repository, environment, or organization level are automatically available through the vars context.

[!NOTE] Configuration variables at the environment level become automatically available after the execution environment declares its environment.

If a configuration variable has not been set, the context returns an empty string for the variable.

The following example shows the use of configuration variables and the vars context throughout the workflow. Each of the following configuration variables has already been defined at the repository, organization, or environment level.

on:
  workflow_dispatch:
env:
  # Set the environment variable using the value of the configuration variable
  env_var: ${{ vars.ENV_CONTEXT_VAR }}

jobs:
  display-variables:
    name: ${{ vars.JOB_NAME }}
    # You can use configuration variables and the `vars` context in dynamic jobs
    if: ${{ vars.USE_VARIABLES == 'true' }}
    runs-on: ${{ vars.RUNNER }}
    environment: ${{ vars.ENVIRONMENT_STAGE }}
    steps:
    - name: Use variables
      run: |
        echo "repository variable : $REPOSITORY_VAR"
        echo "organization variable : $ORGANIZATION_VAR"
        echo "overridden variable : $OVERRIDE_VAR"
        echo "variable from shell environment : $env_var"
      env:
        REPOSITORY_VAR: ${{ vars.REPOSITORY_VAR }}
        ORGANIZATION_VAR: ${{ vars.ORGANIZATION_VAR }}
        OVERRIDE_VAR: ${{ vars.OVERRIDE_VAR }}
        
    - name: ${{ vars.HELLO_WORLD_STEP }}
      if: ${{ vars.HELLO_WORLD_ENABLED == 'true' }}
      uses: actions/hello-world-javascript-action@main
      with:
        who-to-greet: ${{ vars.GREET_NAME }}

job Context

The job context contains information about the currently running job.

Property Name	Type	Description
job	object	This context is different for each job in the workflow run. You can access this context from any step in the job. This object contains all the properties listed below.
job.container	object	Information about the job container.
job.status	string	The current status of the job. Possible values are success, failure, or cancelled.

Example Content of the job Context

This example job context uses a PostgreSQL service container with mapped ports. If the job does not use a container or service container, the job context will only contain the status and check_run_id attributes.

{
  "status": "success"
}

jobs Context

The jobs context is available only in reusable workflows and can only be used to set outputs for reusable workflows.

Property Name	Type	Description
jobs	object	This is only available in reusable workflows and can only be used to set outputs for reusable workflows. This object contains all the properties listed below.
jobs.<job_id>.result	string	The result of the job in the reusable workflow. Possible values are success, failure, cancelled, or skipped.
jobs.<job_id>.outputs	object	The collection of outputs from the job in the reusable workflow.
jobs.<job_id>.outputs.<output_name>	string	The value of a specific output in the job of the reusable workflow.

Example Content of the jobs Context

This example jobs context includes the results and outputs from the job in the reusable workflow run.

{
  "example_job": {
    "result": "success",
    "outputs": {
      "output1": "hello",
      "output2": "world"
    }
  }
}

Example Usage of the jobs Context

This example reusable workflow uses the jobs context to set outputs for the reusable workflow. Note how the outputs flow from the steps to the job, and then to the workflow_call trigger.

name: Reusable workflow

on:
  workflow_call:
    # Map workflow outputs to job outputs
    outputs:
      firstword:
        description: "First output string"
        value: ${{ jobs.example_job.outputs.output1 }}
      secondword:
        description: "Second output string"
        value: ${{ jobs.example_job.outputs.output2 }}

jobs:
  example_job:
    name: Generate output
    runs-on: ubuntu-latest
    # Map job outputs to step outputs
    outputs:
      output1: ${{ steps.step1.outputs.firstword }}
      output2: ${{ steps.step2.outputs.secondword }}
    steps:
      - name: Run step1
        id: step1
        run: echo "firstword=hello" >> $ATOMGIT_OUTPUT
      - name: Run step2
        id: step2
        run: echo "secondword=world" >> $ATOMGIT_OUTPUT

steps Context

The steps context contains information about steps that have been run and have a specified id in the current job.

Property Name	Type	Description
steps	object	This context is different for each step in the job. You can access this context from any step in the job. This object contains all the properties listed below.
steps.<step_id>.outputs	object	The collection of outputs defined for the step.
steps.<step_id>.conclusion	string	The result of the step after applying conclusion. Possible values are success, failure, cancelled, or skipped. When a continue-on-error step fails, outcome is failure, but the final conclusion is success.
steps.<step_id>.outcome	string	The result of the step before applying conclusion. Possible values are success, failure, cancelled, or skipped. When a continue-on-error step fails, outcome is failure, but the final conclusion is success.
steps.<step_id>.outputs.<output_name>	string	The value of a specific output.

Example Content of the steps Context

This example steps context shows two previous steps that have a specified id. The first step has an id of checkout, and the second is generate_number. The generate_number step has an output named random_number.

{
  "checkout": {
    "outputs": {},
    "outcome": "success",
    "conclusion": "success"
  },
  "generate_number": {
    "outputs": {
      "random_number": "1"
    },
    "outcome": "success",
    "conclusion": "success"
  }
}

Example Usage of the steps Context

This example workflow generates a random number as an output in one step, and subsequent steps use the steps context to read the value of that output.

name: Generate random failure
on:
  push:
    branches: main
jobs:
  randomly-failing-job:
    runs-on: ubuntu-latest
    steps:
      - name: Generate 0 or 1
        id: generate_number
        run: echo "random_number=$(($RANDOM % 2))" >> $ATOMGIT_OUTPUT
      - name: Pass or fail
        run: |
          if [[ ${{ steps.generate_number.outputs.random_number }} == 0 ]]; then exit 0; else exit 1; fi

runner Context

The runner context contains information about the execution environment running the current job.

Property Name	Type	Description
runner	object	This context is different for each job in the workflow run. This object contains all the properties listed below.
runner.name	string	The name of the execution environment running the job. This name may not be unique in the workflow run, as the execution environments at the repository and organization levels may use the same name.
runner.os	string	The operating system of the execution environment running the job. Possible values are Linux, Windows, or macOS.
runner.arch	string	The architecture of the execution environment running the job. Possible values are X86, X64, ARM, or ARM64.
runner.tool_cache	string	The path to the directory containing pre-installed tools on the AtomGit-managed execution environment.
runner.environment	string	The environment of the execution environment running the job. Possible values are: codearts-hosted for the AtomGit-provided AtomGit-managed execution environment, and self-hosted for a self-hosted execution environment configured by the repository owner.

Example Content of the runner Context

The following example context comes from a Linux AtomGit-managed execution environment.

{
  "os": "Linux",
  "arch": "X64",
  "name": "Atomgit Actions 2",
  "tool_cache": "/opt/hostedtoolcache",
  "temp": "/home/runner/work/_temp"
}

Example Usage of the runner Context

This example workflow uses the runner context to set the path of the temporary directory for writing logs, and uploads these logs as artifacts if the workflow fails.

name: Build
on:
  push:
    branches: main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - name: Build with logs
        run: |
          mkdir ${{ runner.temp }}/build_logs
          echo "Logs from building" > ${{ runner.temp }}/build_logs/build.logs
          exit 1
      - name: Upload logs on fail
        if: ${{ failure() }}
        uses: actions/upload-artifact@v4
        with:
          name: Build failure logs
          path: ${{ runner.temp }}/build_logs

secrets Context

The secrets context contains the names and values of secrets available for the workflow run. For security reasons, the secrets context is not applicable to composite actions. If you want to pass secrets to a composite action, you need to pass them explicitly as inputs.

ATOMGIT_TOKEN is a secret automatically created for each workflow run and is always included in the secrets context.

[!WARNING] If a secret is used in a workflow job, AtomGit Pipeline will automatically mask the secret when it is printed to the log. You should avoid intentionally printing secrets to the log.

Property Name	Type	Description
secrets	object	This context is the same for each job in the workflow run. You can access this context from any step in the job. This object contains the properties listed below.
secrets.ATOMGIT_TOKEN	string	A token automatically created for each workflow run.
secrets.<secret_name>	string	The value of a specific secret.

Example Content of the secrets Context

The following example content of the secrets context shows the automatic ATOMGIT_TOKEN, as well as two other secrets available for the workflow run.

{
  "atomgit_token": "***",
  "NPM_TOKEN": "***",
  "SUPERSECRET": "***"
}

Example Usage of the secrets Context

This example workflow uses , which requires ATOMGIT_TOKEN as the value of the GH_TOKEN input parameter:

name: Open new issue
on: workflow_dispatch

jobs:
  open-issue:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      issues: write
    steps:
      - name: Run sh
        run: |
          gh issue --repo ${{ atomgit.repository }} \
            create --title "Issue title" --body "Issue body"
        env:
          GH_TOKEN: ${{ secrets.ATOMGIT_TOKEN }}

strategy Context

For workflows with matrices, the strategy context contains information about the matrix execution strategy for the current job.

Property Name	Type	Description
strategy	object	This context is different for each job in the workflow run. You can access this context from any job or step in the workflow. This object contains all the properties listed below.
strategy.fail-fast	boolean	When this evaluates to true, all ongoing jobs will be canceled if any job in the matrix fails.
strategy.job-index	number	The index of the current job in the matrix. Note: This number is zero-based. The index of the first job in the matrix is 0.
strategy.job-total	number	The total number of jobs in the matrix. Note: This number is not zero-based. For example, for a matrix with four jobs, the value of job-total is 4.
strategy.max-parallel	number	The maximum number of jobs that can be run simultaneously using the matrix job strategy.

Example Content of the strategy Context

The following example content of the strategy context comes from a matrix with four jobs and is taken from the last job. Note the difference between the zero-based job-index numbering and the non-zero-based job-total.

{
  "fail-fast": true,
  "job-index": 3,
  "job-total": 4,
  "max-parallel": 4
}

Example Usage of the strategy Context

This example workflow uses the strategy.job-index attribute to set a unique name for the log file of each job in the matrix.

name: Test strategy
on:
  push:
    branches: main

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        test-group: [1, 2]
        node: [14, 16]
    steps:
      - name: Run echo
        run: echo "Mock test logs" > test-job-${{ strategy.job-index }}.txt
      - name: Upload logs
        uses: actions/upload-artifact@v4
        with:
          name: Build log for job ${{ strategy.job-index }}
          path: test-job-${{ strategy.job-index }}.txt

matrix Context

For workflows with matrices, the matrix context contains the matrix properties defined in the workflow file that apply to the current job. For example, if you configure a matrix with os and node keys, the matrix context object includes os and node properties along with the values currently used by the job.

There are no standard properties in the matrix context; only those properties defined in the workflow file are present.

Property Name	Type	Description
matrix	object	This context is only applicable to jobs in the matrix and is different for each job in the workflow run. You can access this context from any job or step in the workflow. This object contains the properties listed below.
matrix.<property_name>	string	The value of the matrix property.

Example Content of the matrix Context

The following example content of the matrix context comes from a job in a workflow with os and node matrix properties defined in the workflow. The job is executing the matrix combination of ubuntu-latest OS and Node.js version 16.

{
  "os": "ubuntu-latest",
  "node": 16
}

Example Usage of the matrix Context

This example workflow uses a matrix with os and node keys. It uses the matrix.os property to set the execution environment type for each job and the matrix.node property to set the Node.js version for each job.

name: Test matrix
on:
  push:
    branches: main

jobs:
  build:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu os:-latest, windows-latest]
        node: [14, 16]
    steps:
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
      - name: Output node version
        run: node --version

inputs Context

The inputs context contains the input properties passed to an action, reusable workflow, or manually triggered workflow. For reusable workflows, the input names and types are defined in the workflow_call event of the reusable workflow, and the input values are passed from the external workflow that calls the reusable workflow via jobs.<job_id>.with. For manually triggered workflows, the inputs are defined in the workflow_dispatch of the workflow.

The properties in the inputs context are defined in the workflow file. They are only available in reusable workflows or workflows triggered by workflow_dispatch.

Property Name	Type	Description
inputs	object	This context is only available in reusable workflows or workflows triggered by the workflow_dispatch event. You can access this context from any job or step in the workflow. This object contains the properties listed below.
inputs.<name>	string or number or boolean or choice	The value of each input passed from the external workflow.

Example Content of the inputs Context

The following example content of the inputs context comes from a workflow that defines build_id, deploy_target, and perform_deploy inputs.

{
  "build_id": 123456768,
  "deploy_target": "deployment_sys_1a",
  "perform_deploy": true
}

Example Usage of the inputs Context in a Reusable Workflow

This example reusable workflow uses the inputs context to get the values of build_id, deploy_target, and perform_deploy inputs passed to the reusable workflow from the caller workflow.

name: Reusable deploy workflow
on:
  workflow_call:
    inputs:
      build_id:
        required: true
        type: number
      deploy_target:
        required: true
        type: string
      perform_deploy:
        required: true
        type: boolean

jobs:
  deploy:
    runs-on: ubuntu-latest
    if: ${{ inputs.perform_deploy }}
    steps:
      - name: Deploy build to target
        run: echo "Deploying build:${{ inputs.build_id }} to target:${{ inputs.deploy_target }}"

Example Usage of the inputs Context in a Manually Triggered Workflow

This example workflow triggered by the workflow_dispatch event uses the inputs context to get the values of the build_id, deploy_target, and perform_deploy inputs passed to the workflow.

on:
  workflow_dispatch:
    inputs:
      build_id:
        required: true
        type: string
      deploy_target:
        required: true
        type: string
      perform_deploy:
        required: true
        type: boolean

jobs:
  deploy:
    runs-on: ubuntu-latest
    if: ${{ inputs.perform_deploy }}
    steps:
      - name: Deploy build to target
        run: echo "Deploying build:${{ inputs.build_id }} to target:${{ inputs.deploy_target }}"

Context Lifecycle Management

In AtomGit Actions, contexts are not loaded all at once when a workflow is triggered. The execution of the workflow follows a strict step-by-step evaluation mechanism. Only when the pipeline orchestration and scheduling engine flows into a specific lifecycle phase will the corresponding context be parsed and injected into the runtime environment. If a context is referenced at the wrong phase before it is injected, it will result in an empty variable or a syntax evaluation error.

The context injection timing in a workflow is divided into four core phases: parsing, scheduling allocation, execution, and archiving.

Context Injection Timing

Lifecycle Phase	Injection/Evaluation Timing Explanation	Injected Contexts	Data Content and Technical Definition
1. Parsing Phase	1. The engine receives the Webhook or manual trigger event, initially parses and validates the YAML structure. 2. Builds the job dependency DAG and expands the concurrency matrix.	ATOMGIT inputs vars matrix strategy	Global baseline and input data • ATOMGIT: Repository metadata, trigger event payload (Payload), commit hash, etc. • inputs: Parameters passed when the workflow is manually triggered or called by an upstream. • vars: Predefined plaintext variables at the organization/repository/environment level. Job orchestration and topology data • needs: After the preceding dependent job (needs: xxx) completes, its status and output products. • matrix: During the expansion of the concurrency matrix, the specific matrix dimension parameters for the current job instance. • strategy: The scheduling strategy configuration for the current job (such as concurrent upper limit, failure strategy).
2. Scheduling Allocation Phase	When the job is successfully allocated to a specific Runner physical node or container.	runner secrets	Runtime environment and sensitive data • runner: Hardware and system environment of the target machine. • secrets: Encrypted credentials. Decrypted and injected only after secure allocation,严禁 in the job-level if read.
3. Execution Phase	When the Runner receives the complete instruction and begins to execute the specific steps (steps) code sequentially.	env job steps	Runtime dynamic state data • env: Environment variables, dynamically overridden at the workflow -> job -> step hierarchy when reaching the node. • job: Real-time execution status of the current job (e.g., success, cancelled). • steps: Output results (outputs) and termination status of steps that have been executed in the current job.
4. Archiving Phase	(Special scenario) When all jobs of a reusable workflow are completed and need to return results to the upstream caller.	jobs	Reusable workflow output mapping • jobs: Only available for workflow_call triggered reusable workflows. Used to evaluate in the outputs block at the top of the workflow, extracting and exposing the output of a specific job inside to the upstream caller.