Is there any environment variable defined in IBM RAD/WAS which points to the current workspace?
Not sure I understand correctly your answer, do you mean in the OS Environment Variables, like PATH? There is no such thing.
If, however, you want to use a variable within RAD that points to your current workspace for the purposes of running an application and you want to resolve a JAR, you can use the variable ${eclipse_home}.
Again, more information about the purpose of such variable will be helpful
Related
I need to deploy the same project and the same version on different environments. Each environment requires its own values for the given variables, e.g. ENV1 requires var1a, var1b, var1c and ENV2 requires var2a, var2b and var2c. You cannot have a combination var1a and var2b. That means that I need to run exactly the same build but with different set of variables.
There are about 20 variables and 50 environments so changing them manually 1000 times per version is not exactly an option.
I can create a different build definition for each set of variables' values and end up with 50 definitions, but that seems a little bit redundant. Not to mention in case I want to remove a step, I will need to update 50 definitions.
Can I somehow link a variable group to a build configuration and make the build definition switch the values automatically?
If you would like to not use another tool like Octopus Deploy (regradless that you could achieve the needed work with it), and stick to your TFS, assuming that you are on TFS 2015 or higher version already, you could probably take advantage of the creating and deploying release using Release Definitions through the Release Management and use Custom Variables to have the same variable to have different value based on the Environment you are going to use it for.
I'm working with TFS on-premise.
My issue is that during a release I have two agent phases separated by a manual intervention.
In the first agent phase, I set a variable with:
Write-Verbose $("##vso[task.setvariable variable={0};]{1}" -f $variablename, $variable)
Problem is that in the second agent phase, this variable doesn't exist anymore, even if the same agent is used for the second release phase.
How may I pass a variable between two agent phases during the same release?
There is no way to persist variables (no matter powershell variables or VSTS user defined variables) between two agent phases (and environments) for now.
And there is a related issue Variables set via logging commands are not persistent between agents, you can follow up.
The work around for now is define the variable again in next agent phase.
You can share a variable between the agent phases by using the TFS Rest API and creating a new variable in the release.
You can create a helper module to facilitate this task.
Get the release by using the environment variable $Env:Release_ReleaseId.
Add a NoteProperty, using Add-Member, to the variables hashtable of the release returned in step 1, where the name is your desired variable name and the value is a ConfigurationVariableValue.
Save the release with the added variable.
In order to use this approach, you would set the variable in your first agent. Then, in the second agent, you can simply read the TFS variable using the $(VariableName) semantic.
I've used the "Variable dehydration task" to write the value to my artifact folder in a build pipeline. I then read the json with inline-powershell. Currently, I'm reading it on every task in my release pipeline, which seems mental to me, but it sort of works. You ought to be able to set a global or env? variable and use that instead. Supposedly fixed in 2017, but I'm using 2015.
The right way to do it is using Variablegroups to persist between pipelines: https://learn.microsoft.com/en-us/azure/devops/pipelines/library/variable-groups?view=azure-devops&tabs=yaml
In TFS 2017, I set a variable in first environment during the execution using the below command
$myValue= "myValue"
Write-Host ("##vso[task.setvariable variable=myValue;]$myValue")
Is it possible to access this variable in the 2nd environment in the same release?
No, you are using a environment-level variable which for values that vary from environment to environment (and are the same for all the tasks in an environment).
However, this could be achieved, you just need to use release definition variables instead.
Share values across all of the environments by using release
definition variables. Choose a release definition variable when you
need to use the same value across all the environments and tasks in
the release definition, and you want to be able to change the value in
a single place. You define and manage these variables in the Variables
tab in a release definition.
More details about variables in Release Management, please refer this tutorial.
In Jenkins, is it possible to export windows batch variables as build parameters? I know using build parameters inside windows batch blocks is, I use it a lot.
For example, I have a windows batch block that creates a variable, say A, like
SET A="MyVar"
Is it possible to use it in running MSBuild, passing it like it was a build parameter, in the (working) syntax of /p:AssemblyName=%A% or /p:AssemblyName=${A} ?
Neither of these seem to work (my variable is always empty).
Update: #Tuffwer suggested using the EnvInject plugin. I have been trying, but so far without success. Here's a sample I created to illustrate my original intent:
I want to create a variable which contents will be determined based on a condition applied in one of the build parameters. Then, I want to use that variable as a parameter to the MsBuild command line, using the /p:[Key]=[Value] syntax (which requires the Jenkins MsBuild plugin, if I am not wrong).
I still can't get this to work, now using EnvInject. I need to reference the value of a windows batch variable inside a further build step.
Update II: I turned into Environment Script Plugin, which did the job for me.
Tuffwer suggested using the EnvInject plugin, I tried did not succeed attaining what I intended. I edited my post including my EnvInject attempt, but in the meantime went searching again for other solutions.
This time I came across the Environment Script Plugin, which did the job for me.
Steps:
Mark Generate environment variables from script
For each variable you want to "export", you need to issue an echo [varName]=[value] statement.
That's all.
My build then creates an assembly named either TRUE.exe or FALSE.exe, depending on the build parameter MyBool value.
I feel I am missing something extremely basic; yet I have spent hours to no avail. I am trying to get a TFS build working and for the life of me I cannot figure out where this property gets set from.
I have picked up a TFS 2010 project from a team member that cannot help me at this time.
I have a simple TFS build that builds a solution.
In the tfproj file I have:
<SolutionToBuild Include="$(BuildProjectFolderPath)/MySolution.sln">
This seems to work, but for the life of me I cannot figure out how. I have not set the variable $(BuildProjectFolderPath) anywhere or anything resembling the correct path to MySolution.sln.
I have checked both the build definition, the build script, and the environment variables on the build box and I cannot figure out where the path corresponding to $(BuildProjectFolderPath) comes from.
Can someone help me unravel this black magic ?
Your build is actually performed by MSBuild. When MSuild starts, it gets some environment type of variables initialized that are project / solution specific. For example on the build server, the build agent will have injected its BuildProjectFolderPath value in MSBuild, that is used to resolve the macro that is in your tfsproj file.
No magic, just the environment that startup up to process your request supplies those values.