After my first article about GitHub Actions basics, I want to share how I handle variables and control my workflows. This is where GitHub Actions becomes really powerful.<\/p>\n
Variables can be defined at three levels, and they override each other in a specific order. Let me show you from my actual workflow:<\/p>\n
name: 08 - Using Variables\n\non: workflow_dispatch\n\nenv:\n WORKFLOW_VAR: 'I am a workflow env var'\n OVERWRITTEN: 'I will be overwritten'\n UNDEFINED_VAR_WITH_DEFAULT: ${{ vars.UNDEFINED_VAR || 'default value' }}\n\njobs:\n echo:\n runs-on: ubuntu-latest\n env:\n JOB_VAR: 'I am a job env var'\n OVERWRITTEN: 'I have been overwritten at the job level'\n steps:\n - name: Print Env Variables\n env:\n STEP_VAR: 'I am a step env var'\n step_var2: 'I am another step env var'\n run: |\n echo \"Step env var: ${{ env.STEP_VAR }}\"\n echo \"Step env var 2: $step_var2\"\n echo \"Job env var: ${{ env.JOB_VAR }}\"\n echo \"Workflow env var: ${{ env.WORKFLOW_VAR }}\"\n echo \"Overwritten: ${{ env.OVERWRITTEN }}\"<\/code><\/pre>\nWhat happens here:<\/p>\n
- OVERWRITTEN starts as “I will be overwritten” at workflow level<\/li>
- Job level changes it to “I have been overwritten at the job level”<\/li>
- Step level would override both if we defined it there<\/li><\/ul>\n
The priority is: Step > Job > Workflow<\/p>\n
Two Ways to Access Variables<\/h3>\n
I discovered you can access variables in two ways:<\/p>\n
run: |\n echo \"Using env context: ${{ env.STEP_VAR }}\"\n echo \"Using shell variable: $step_var2\"<\/code><\/pre>\nBoth work, but ${{ env.VAR }} is safer because it works everywhere in YAML, not just in run: commands.<\/p>\n
Handling Undefined Variables<\/h3>\n
This is something I use a lot – providing default values:<\/p>\n
env:\n UNDEFINED_VAR_WITH_DEFAULT: ${{ vars.UNDEFINED_VAR || 'default value' }}<\/code><\/pre>\nIf UNDEFINED_VAR doesn’t exist, it uses ‘default value’ instead of failing.<\/p>\n
Repository and Organization Variables<\/h3>\n
GitHub lets you set variables at different scopes:<\/p>\n
jobs:\n echo2:\n runs-on: ubuntu-latest\n steps:\n - name: Print Variables\n run: |\n echo \"Org var: ${{ vars.ORG_VAR }}\"\n echo \"Org overwritten var: ${{ vars.OVERWRITTEN_VAR }}\"\n echo \"Repo var: ${{ vars.REPOSITORY_VAR }}\"<\/code><\/pre>\nYou create these in GitHub Settings:<\/p>\n
- Organization variables: Shared across all repos in your org<\/li>
- Repository variables: Specific to one repo<\/li>
- Environment variables: Specific to deployment environments (staging, prod, etc.)<\/li><\/ul>\n
Environment-Specific Variables<\/h3>\n
This is really useful for different deployment targets:<\/p>\n
jobs:\n echo-prod:\n runs-on: ubuntu-latest\n environment: prod # This is the key!\n steps:\n - name: Print Prod Variables\n run: |\n echo \"Org var: ${{ vars.ORG_VAR }}\"\n echo \"Environment var: ${{ vars.TARGET_VAR }}\"<\/code><\/pre>\nWhen you set environment: prod, GitHub loads variables you defined for that environment. Same variable name can have different values in staging vs prod.<\/p>\n
Expressions: Making Decisions<\/h3>\n
Expressions use the ${{ }} syntax and let you add logic to your workflows.<\/p>\n
Basic Conditionals<\/h3>\n
Here’s my workflow that uses expressions:<\/p>\n
name: 07 - Using Expressions\nrun-name: 07 - Using Expressions | DEBUG - ${{ inputs.debug && 'ON' || 'OFF' }}\n\non:\n workflow_dispatch:\n inputs:\n debug:\n type: boolean\n default: false\n\njobs:\n echo:\n runs-on: ubuntu-latest\n steps:\n - name: '[debug] Print start-up data'\n if: inputs.debug\n run: |\n echo \"Triggered by: ${{ github.event_name }}\"\n echo \"Branch: ${{ github.ref }}\"\n echo \"Commit SHA: ${{ github.sha }}\"\n echo \"Runner OS: ${{ runner.os }}\"\n - name: '[debug] Print when triggered from main'\n if: inputs.debug && github.ref == 'refs\/heads\/main'\n run: echo \"I was triggered from main\"\n - name: Greeting\n run: echo \"Hello, world\"<\/code><\/pre>\nWhat’s happening:<\/p>\n
- if: inputs.debug – step only runs if debug is true<\/li>
- if: inputs.debug && github.ref == ‘refs\/heads\/main’ – runs only if BOTH conditions are true<\/li>
- The run-name shows ON or OFF depending on debug value using ternary operator<\/li><\/ul>\n
The Context System<\/h3>\n
GitHub provides different contexts you can use in expressions:<\/p>\n
steps:\n - name: Display information\n run: |\n echo \"Event Name: ${{ github.event_name }}\"\n echo \"Ref: ${{ github.ref }}\"\n echo \"SHA: ${{ github.sha }}\"\n echo \"Actor: ${{ github.actor }}\"\n echo \"Workflow: ${{ github.workflow }}\"\n echo \"Run ID: ${{ github.run_id }}\"\n echo \"Run number: ${{ github.run_number }}\"<\/code><\/pre>\nI use these for debugging and creating unique identifiers for my builds.<\/p>\n
Useful Functions for Workflow Control<\/h3>\n
GitHub Actions has built-in functions that I use all the time:<\/p>\n
Status Check Functions<\/h3>\nname: 09 - Using Functions\n\non:\n pull_request:\n workflow_dispatch:\n\njobs:\n echo1:\n runs-on: ubuntu-latest\n steps:\n - name: Print PR title\n run: echo \"${{ github.event.pull_request.title }}\"\n - name: Bug step\n if: ${{ !cancelled() && contains(github.event.pull_request.title, 'fix') }}\n run: echo \"I am a bug fix\"\n - name: Sleep for 20 seconds\n run: sleep 20\n - name: Failing step\n run: exit 1\n - name: I will be skipped\n if: ${{ success() }}\n run: echo \"I will print if previous steps succeed.\"\n - name: I will execute\n if: ${{ failure() }}\n run: echo \"I will print if any previous step fails.\"\n - name: I will execute\n if: ${{ !cancelled() }}\n run: echo \"I will always print, except when the workflow is cancelled.\"<\/code><\/pre>\nKey functions:<\/p>\n
- success() – true if all previous steps succeeded<\/li>
- failure() – true if any previous step failed<\/li>
- cancelled() – true if workflow was cancelled<\/li>
- contains(string, substring) – checks if string contains substring<\/li><\/ul>\n
The toJSON() Function<\/h3>\n
This one helped me a lot when debugging:<\/p>\n
- name: Print PR labels\n run: |\n cat << EOF\n ${{ toJSON(github.event.pull_request.labels) }}\n EOF<\/code><\/pre>\nIt converts objects to readable JSON so you can see what data is available.<\/p>\n
Controlling Execution Flow<\/h3>\n
This is where everything comes together. Here’s my real workflow:<\/p>\n
name: 10 - Controlling the Execution Flow\n\non:\n workflow_dispatch:\n inputs:\n pass-unit-tests:\n type: boolean\n description: Whether unit tests will pass or not\n default: true\n\njobs:\n lint-build:\n runs-on: ubuntu-latest\n steps:\n - name: Lint and build\n run: echo \"Linting and building project\"\n unit-tests:\n runs-on: ubuntu-latest\n steps:\n - name: Running unit tests\n run: echo \"Running tests...\"\n - name: Failing tests\n if: ${{ !inputs.pass-unit-tests }}\n run: exit 1\n deploy-nonprod:\n runs-on: ubuntu-latest\n needs:\n - lint-build\n - unit-tests\n steps:\n - name: Deploying to nonprod\n run: echo \"Deploying to nonprod...\"\n e2e-tests:\n runs-on: ubuntu-latest\n needs:\n - deploy-nonprod\n steps:\n - name: Running E2E tests\n run: echo \"Running E2E tests\"\n load-tests:\n runs-on: ubuntu-latest\n needs:\n - deploy-nonprod\n steps:\n - name: Running load tests\n run: echo \"Running load tests\"\n deploy-prod:\n runs-on: ubuntu-latest\n needs:\n - e2e-tests\n - load-tests\n steps:\n - name: Deploying to prod\n run: echo \"Deploying to prod...\"<\/code><\/pre>\nThe execution order:<\/p>\n
- lint-build and unit-tests run in parallel (no dependencies)<\/li>
- deploy-nonprod waits for both to finish (needs both)<\/li>
- e2e-tests and load-tests run in parallel after deploy-nonprod<\/li>
- deploy-prod waits for both tests to complete<\/li><\/ol>\n
Important:<\/strong> If unit-tests fails, deploy-nonprod never runs because of the needs: dependency.<\/p>\nWhat I Learned<\/h3>\n- Use environment-specific variables:<\/strong> Don’t hardcode values. Use vars.MY_VAR and set different values for dev\/staging\/prod.<\/li>
- Always provide defaults:<\/strong> ${{ vars.MY_VAR || ‘default’ }} saves you from errors when variables aren’t set.<\/li>
- Use status functions carefully:<\/strong> success() checks ALL previous steps. If you want to run cleanup even after failures, use if: always() or if: !cancelled().<\/li>
- The needs: keyword is powerful:<\/strong> It creates dependencies between jobs. Use it to build proper CI\/CD pipelines.<\/li>
- Test with workflow_dispatch:<\/strong> I add boolean inputs to test different scenarios without changing code:<\/li>
- Debug with expressions:<\/strong> Show values in run-name to see what’s happening:<\/li><\/ol>\n
Real-World Example<\/h3>\n
Here’s how I combine everything in my workflows:<\/p>\n
name: Deploy Application\nrun-name: Deploy to ${{ inputs.environment }} | Dry Run - ${{ inputs.dry-run && 'YES' || 'NO' }}\n\non:\n workflow_dispatch:\n inputs:\n environment:\n type: choice\n options:\n - dev\n - staging\n - prod\n required: true\n dry-run:\n type: boolean\n default: false\n\nenv:\n APP_VERSION: ${{ vars.APP_VERSION || 'latest' }}\n\njobs:\n deploy:\n runs-on: ubuntu-latest\n environment: ${{ inputs.environment }}\n if: ${{ !inputs.dry-run }}\n steps:\n - name: Deploy to ${{ inputs.environment }}\n run: echo \"Deploying version ${{ env.APP_VERSION }} to ${{ inputs.environment }}\"<\/code><\/pre>\nThis workflow:<\/p>\n
- Lets me choose the environment<\/li>
- Shows me what will happen in the run name<\/li>
- Has a dry-run option to test without deploying<\/li>
- Uses environment-specific variables<\/li>
- Only deploys if dry-run is false<\/li><\/ul>","protected":false},"excerpt":{"rendered":"
After my first article about GitHub Actions basics, I want to share how I handle variables and control my workflows. This is…<\/p>\n","protected":false},"author":2,"featured_media":66,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_rezaops_part":"2","_rezaops_linkedin_url":"https:\/\/www.linkedin.com\/pulse\/variables-expressions-control-flow-github-actions-reza-chegini-bal2c\/","footnotes":""},"categories":[27,10],"tags":[30,8,29,6],"series":[28],"class_list":["post-63","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ci-cd","category-devops","tag-ci-cd","tag-devops","tag-github-actions","tag-yaml","series-github-actions"],"jetpack_featured_media_url":"https:\/\/rezachegini.com\/wp-content\/uploads\/2026\/10\/variables-expressions-control-flow-github-actions-cover.png","_links":{"self":[{"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/posts\/63","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=63"}],"version-history":[{"count":1,"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/posts\/63\/revisions"}],"predecessor-version":[{"id":64,"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/posts\/63\/revisions\/64"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/media\/66"}],"wp:attachment":[{"href":"https:\/\/rezachegini.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=63"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=63"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=63"},{"taxonomy":"series","embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=%2Fwp%2Fv2%2Fseries&post=63"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}