I have a job which needs to refer to the environment variable set in the command in the same step prior to be set. GitHub Actions sets the variable correctly but does not refer to it in the same step, leaving me with an empty value.
jobs:
test-commands:
runs-on: ubuntu-latest
steps:
- run: |
echo "image=2.1" >> $GITHUB_ENV
echo "image_ref=$image" >> $GITHUB_ENV
echo "image_ref_2=${{env.image}}" >> $GITHUB_ENV
- run: echo ${{env.image}} ${{env.image_ref}} ${{env.image_ref_2}}
This is a sample job of what I am trying to accomplish, as shown neither of the methods work , with only the image variable being printed properly in the 2nd step, and the other variables being set as null.
I was not able to find any reference in the docs which mentioned that variables can be referred in the next step only.
Any suggestions to set this properly are most welcome. Thanks in advance!
From the documentation:
You can make an environment variable available to any subsequent steps
in a workflow job by defining or updating the environment variable and
writing this to the GITHUB_ENV environment file. The step that creates
or updates the environment variable does not have access to the new
value, but all subsequent steps in a job will have access. The names
of environment variables are case-sensitive, and you can include
punctuation. For more information, see "Environment variables."
So in your case, you can write your result to a bash variable that you can use in your step, then you export that same variable to GITHUB_ENV.
Example:
steps:
- run: |
IMAGE=2.1
echo "image=${IMAGE}" >> $GITHUB_ENV
echo "image_ref=${IMAGE}" >> $GITHUB_ENV
- run: echo ${{env.image}} ${{env.image_ref}}
Run:
Related
Background
I have a number of different repos in my monorepo project.
For my api and common-services repo, i want to run a test command
For my frontend repo, I want to run a test2 command
Current
Currently, when running the test command for the frontend repo, the command variable is provided in the job as an Array.
Expected
I expect the command variable to always be a string
Note: I have simplified my test workflow to represent the problem. I do not want to manually specify every test configuration as an include.
Oops, I was confusing the array input of the original matrix with the includes configuration ...
wrong
matrix:
repo: [api, common-services]
command: [test]
include:
- repo: frontend
command: [test2]
- repo: common-lib
command: [test2]
correct
matrix:
repo: [api, common-services]
command: [test]
include:
- repo: frontend
command: test2 # DO NOT SPECIFY AS ARRAY HERE
- repo: common-lib
command: test2 # DO NOT SPECIFY AS ARRAY HERE
I have 2 JSON files:Parameters.json and updatedParam.json
I want to write a yml script that allows me to take both the json files and patch the change done in Parameters.json to updatedParam.json
I am trying to trigger a pipeline whenever a change is made in the Parameters.json file.
Thanks in advance.
I want to write a yml script that allows me to take both the json
files and patch the change done in Parameters.json to
updatedParam.json
DevOps doesn't support this feature, if you need, you need to design your own code.
And if you want your pipeline triggered by a specific file like Parameters.json, your pipeline should be like this:
trigger:
branches:
include:
- main
paths:
include:
- test/Parameters.json
pool:
vmImage: ubuntu-latest
steps:
- script: echo Hello, world!
displayName: 'Run a one-line script'
- script: |
echo Add other tasks to build, test, and deploy your project.
echo See https://aka.ms/yaml
displayName: 'Run a multi-line script'
I'm starting to learn github actions (converting from jenkins piplines). I am not super familiar with yaml.
I cannot figure out when or why variables should be referenced using double curly braces vs single curly braces. I have a feeling there is an important distinction here....
Can you clue me in?
name: sample
on:
workflow_dispatch
env:
MY_VAR: "something"
jobs:
do_things:
runs-on: ubuntu-latest
steps:
- name: "Step 1"
run: echo "${MY_VAR}"
- name: "Step 2"
run: echo "${{env.MY_VAR}}"
This line:
run: echo "${MY_VAR}"
is literally running a bash script that says:
echo "${MY_VAR}"
so in this case, ${MY_VAR} is expanded according to bash's rules; in this case it will just print the environment variable MY_VAR, but you can do all sorts of crazy things with bash's parameter expansion.
On the other hand, this line:
run: echo "${{env.MY_VAR}}"
is expression syntax for GitHub Actions and will be expanded by the GitHub Actions runner. In this case, the variable MY_VAR that is in your environment context will be replaced in the shell script.
The literal shell script that will executed will have the environment variable value in it. So if MY_VAR=foo, then the literal bash script that will be run is:
echo "foo"
So although the outcome is similar at the end, the means of getting there is very different, based on when the substitution happens.
I have a bash script that sets a series of environment variables.
My action includes the following two steps:
- name: Set env variables
run: source ./setvars.sh
- name: dump env variables
run: env
I notice setvars.sh runs successfully, but all of the variables defined inside it are missing after the steps.
How can I use a bash .sh script to add environment variables to the context of the workflow?
I don't see environment variables defined by sourcing file in GitHub Actions workflow.
I only see them defined as map (key-value) at the job or workflow level (since oct. 2019).
See if you can cat your file and append its content to GITHUB_ENV.
I am setting a couple of env variables on build time when deploying on vercel using "amondnet/vercel-action#v19.0.1+3" github action.
Everything works fine when I set just one variable, but when I set multiple variables as described in Vercel's documenation here: https://vercel.com/docs/cli#commands/overview/unique-options/build-env, I get the following error when running the action:
Error! The specified file or directory "PR_NUMBER=423]" does not exist.
The command the action is trying to run is as follows:
/usr/local/bin/npx vercel --build-env [NODE_ENV=pr PR_NUMBER=423] -t *** -m
It should be:
/usr/local/bin/npx vercel --build-env NODE_ENV=pr --build-env PR_NUMBER=423 -b KEY=value