Every time we use core.exportVariable which, as far as I know, is the canonical way to export a variable in #action/core and, consequently, in github-script, you get an error such as this one:
Warning: The set-env command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/
That link leads to an explanation of environment files, which, well, are files. Problem is files do not seem to have such a great support in github-script. There's the #actions/io package, but there's no way to create a file with that.
So is there something I'm missing, or there is effectively no way to create an environment file form inside a github-script step?
You no longer need the actions/github-script nor any other special API to export an environment variable. According to the Environment Files documentation, you can simply write to the $GITHUB_ENV file directly from the workflow step like this:
steps:
- name: Set environment variable
run: echo "{name}={value}" >> $GITHUB_ENV
The step will expose given environment variable to subsequent steps in the currently executing workflow job.
Related
I'm trying to write a file in my GitHub repo with GitHub Actions. When reading the docs, I stumbled across this:
Actions can communicate with the runner machine to set environment
variables, output values used by other actions, add debug messages to
the output logs, and other tasks.
Most workflow commands use the echo command in a specific format,
while others are invoked by writing to a file. For more information,
see "Environment files".
echo "::workflow-command parameter1={data},parameter2={data}::{command value}"
I don't know Ansible so I don't understand if this is YAML syntax or Ansible syntax.
I've tried to search Google and Stack Overflow but no results for double colon or ::
Can someone give me the link to the appropriate doc for :: or explain what this command does?
in other words, what does the example in my post throws in the shell? where are data and parameter1 and parameter2 defined if they are (in the yml, in the shell/env)? is command value a value i can reuse in the yml or in the shell?
The ::command can be logged to the console by any script or executable. They are special strings the GitHub runner will detect, interpret and then take the appropriate action on.
They are essentially the communication mechanism between the runner and the thing it's currently running. Anything that can write to the console can issue these strings.
It's totally up to you to build these stings, to inject any parameters these 'magic strings' require to function.
The docs you've found are the right docs on these to understand how to log there strings and what commands there are available to you.
If you're building a GitHub action using the JavaScript/Typescript toolkit, then it provides nice wrapper functions for these commands. The JavaScript SDK also gives you a sneak peak into how to composekthese strings.
If you're building a composite action, container task or are directly issueing commands from a script block in the workflow, then it's up to you to build the correct strings and log these to the console.
More details:
https://github.com/actions/toolkit/blob/main/packages/core/README.md
https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions (you had found that already)
Communicating through the console is the lowest common denominator between any tools running on just about any platform and requires no interprocess communication if any kind. It's the simplest way to communicate from a child process to it's parent.
You'd use the command to set an output variable.
echo "::set-output name=name::value"
To be able to reference the value cross at you'd reference any output variable from any action.
Or set an environment variable which will be set for the next job: echo "action_state=yellow" >> $GITHUB_ENV
See: https://stackoverflow.com/a/57989070/736079
This documentation states that secret variables are
Not decrypted into environment variables. So scripts and programs run by your build steps are not given access by default.
One of my build tasks require that an environment variable be set that is stored in a secret variable. Does this mean it's impossible to do this using secret varaibles in VSTS? If not, how do I do this?
For further background, I'm trying to code sign my electron app using electron-builder. It requires that two environment variables be set: CSC_LINK and CSC_KEY_PASSWORD. One of these is the password to a code signing certificate so needs to be kept secure.
Set Environment Variable
Use a Command Line task, like this:
target_environment_variable now contains the value of secret_variable.
Verify
Add a subsequent Command Line task that writes all environment variables to a disk file, like this: (note: in the Arguments text box, write to a folder that both you and build agent can access):
Queue the build definition, then view the file containing the environment variables:
When using the YAML-syntax this can be achieved too:
steps:
- script: |
echo %MYSECRET%
env:
MySecret: $(Secret_Variable)
You can supply variables to pass to tasks in the Variables page of the build definition:
Then they can be passed in to a task as an input like so:
I am using TFS2015 Release Management and Powershell DSC to manage the deployment of applications - previously I was using RM2013.
One thing I have noticed is that in RM2013, in my Powershell DSC scripts I was able to access variables such as $applicationPath - which was populated with the TFS Build Drop location, for use in the DSC scripts and MOF creation.
In RM2015 it doesn't appear that this works? I have tried using the variables listed here: https://msdn.microsoft.com/en-us/Library/vs/alm/Build/scripts/variables
However none of these ever seem to be populated?
Is there actually a way of using these RM2015 system & build variables from within a PS DSC script now?
Kind regards
Try to use the corresponding generated environment variables (for example $env:Build.DefinitionName).
If it not work try more ways such as $env:Build_DefinitionName or $(Build.BuildNumber) and $(Build_BuildNumber)
Just as the relevant documentation mentioned:
Any text input can reference a variable by using the $(variable_name)
syntax and will be substituted with the actual value at run-time. All
variables are also exported to the environment as upppercase and any .
are replaced with _. In scripts you can reference variables via the
environment, i.e. %VARIABLE_NAME%, $VARIABLE_NAME, $env:VARIABLE_NAME,
depeding on the operating system.
I'm trying to set up a new build configuration in TeamCity using the Powershell runner. However, I can't seem to find a way to access the TeamCity System Properties in the build script. I've seen hints that it is possible, but cannot find documentation on how to do it.
I have tried accessing the system properties using Powershell variable syntax, $variable. I have also printed out all variables in memory and see no teamcity variables to use.
Is this possible with the Powershell runner, and if so what is the syntax necessary to get it working?
TeamCity will set up environment variables, such as build.number (you can see a list of these within TeamCity).
In Powershell you can access environment variables using the env "provider", e.g.
$env:PATH
TeamCity variables are accessible by replacing the . with a _, so the build.number variable can be accessed as
$env:build_number
As it says in the TeamCity documentation, the system parameters are passed to the build script runner, but not all build script runners know what to do with them. In the case of the Powershell script runner, when using a script file, they don't propagate down to your scripts.
It's occurred to me to write a psake-optimized build runner that does, but in the meantime you can do one of the following:
explicitly map any of the TeamCity build properties to script parameters using the parameter expansion that's available within the Script Source box. eg .\build.ps1 -someParam:%build.name%
use environment parameters, which can be accessed explicitly within PowerShell using $env:NAME_IN_TEAMCITY syntax, eg $env:TEAMCITY_VERSION, or looped over and pushed into variable scope
access the build properties file that TeamCity makes available during the build. The file is available at $env:TEAMCITY_BUILD_PROPERTIES_FILE, and if you load the XML version it's fairly easy to loop through and push them all into scope (though you do get everything as a string of course). I posted a gist on how to do this (https://gist.github.com/piers7/6432985). Or, if using Psake, modify the script above to return you a hashtable which you can pass directly to Psake's -properties argument.
It is posible. Here is example how to pass system properties into PSake script:
& .\psake.ps1 -parameters #{build_number=%build.number%; personal_build=%build.is.personal%}
If you don't use Psake, you can define your variables like this:
$build_number = %build.number%
The %build.number% part will be replaced with TeamCity provided data. I think, it works only in Source code script input mode.
I created a meta-runner that will pass through System parameters to parameters declared in the Powershell script. It's not perfect (if you put '# in your source it will break) but it works for what I needed, you can find it here: https://gist.github.com/anonymous/ef60ada3f48f0fb25093
I'm trying to set an environment variable in a build script with phing.
This is normally done command line like this:
export MY_VAR=value
In Phing I did the following but it isn't working.
<exec command="export MY_VAR=value" />
I see that this is quite an old question, but I don't think it has been answered in the best way. If you wish to export a shell variable, for example say you are running phpunit from phing and want to do an export before invoking phpunit, try:
<exec command="export MY_VAR=value ; /path/to/phpunit" />
Simply do the export and invoke your command inside the same exec tag. Separate the export statement and the shell executable with a semicolon as shown. Your script will be able to access the value using the standard php function:
$myVar = getenv('MY_VAR');
Bold claim: There is no way to set/export a (Unix) shell variable in PHP so that it is visible inside the scope that started the php script.
php myfile.php (does putenv or shell_exec('export foo=bar');)
echo $foo
Will return nothing.
As PHP can not do it so neither can phing.
Accessing shell environment variables accross multiple script runs (if its that what you want) seems also like an unideal design decision, pretty stateful.
Apart from that I'd urge you to stick to phing and learn its lean lesson. Phing helps stateless thinking to some degree.
I'd never heard of phing before, but this looks very promising as a build tool. Thanks for posting! I looked through the doc on phing.info, I found the following possibility:
#0 I would like to clarify one point. Are you saying that
prompt$ > export MY_VAR=value
prompt$ > phing build.xml
doesn't set MY_VAR to value so it is visible inside the running phing processes? I'd be surprised, but I would understand if this is not how you want to run your build script.
#1 I think in the context of a build tool, a feature like exec is meant to run a stand-alone program, so, while the exec may run and set MY_VAR, this is all happening in a subprocess that disappears immediately as the exec finishes and continues processing the next task in the build.xml.
If you're just trying to ensure that your phing script runs with specific values for env_vars, you could try
Command-line arguments:
....
-D<property>=<value>
// Set the property to the specified value to be used in the buildfile
So presumably, you can do
phing -DMY_VAR=value build.xml
#2 did you consider using a properites file?
See http://www.phing.info/docs/guide/stable/chapters/appendixes/AppendixF-FileFormats.html
and scroll down for info on build.properties
#3 also ...
Phing Built-In Properties
Property Contents
env.* Environment variables, extracted from $_SERVER.
you would access them with something like
${env.MY_VAR}
#4 This looks closer to what you really want
<replacetokens>
<token key="BC_PATH" value="${top.builddir}/"/>
<token key="BC_PATH_USER" value="${top.builddir}/testsite/user/${lang}/"/>
</replacetokens>
I hope this helps.