I know how to export/share an artifact from one stage/job to another. In my job configuration, I can say "place artifact 'My artifact' in into destination directory 'foo'" That works and all, but in my job, I'm calling a script where I want to pass that artifact as a parameter. How can I tell what that artifact's name is? I can't pass foo/* as an argument to the task Script as the * is literally passed instead of shell expanded, even if I mark the Interpreter as Shell.
It seems that there should be some sort of ${bamboo.artifact} type of variable that I could pass, but I was unable to locate something. I know the Bamboo name of the artifact, so it seems like there should be a way to know exactly what the variable name is without having to resort to shell wildcarding hacks.
I looked at https://confluence.atlassian.com/bamboo/sharing-artifacts-359400060.html#Sharingartifacts-Sharingartifactsbetweenjobs and https://confluence.atlassian.com/bamboo0610/bamboo-variables-980469487.html
Related
I'm looking at VSTS Build with the eyes of a Teamcity user. I'd like to set up multiple builds that each have the same set of parameters for MSBuild to use. For example, I'd like all my builds to share the CreateHardLinksForCopyFilesToOutputDirectoryIfPossible parameter.
I know I can manually write out /p:CreateHardLinksForCopyFilesToOutputDirectoryIfPossible=true in each build configuration I set up, but I'd prefer to set this once using the variable system. However, when I set my variables using the variable editor, the VSTS agent converts variable names to upper case (as well as converting "." to "_" and other transforms), which means msbuild doesn't look at them (it was expecting the correct PascalCased version). I have verified this by echo-ing out all current environment variables, during build. I can't see any documentation on why this happens.
Is there a pattern to pass MSBuild parameters in via the variable system?
For VSTS variable name, it’s case-insensitive. You just need to focus on the variable’s value.
Such as if you have the variable tHisIsMixEdCase with the value /p:CreateHardLinksForCopyFilesToOutputDirectoryIfPossible=true.
Then no matter to use $(THISISMIXEDCASE) or $(tHisIsMixEdCase) in MSBuild arguments option, both of them work same as using /p:CreateHardLinksForCopyFilesToOutputDirectoryIfPossible=true directly.
I am creating a deployment in Bamboo. I have some variables set up under the deployment plan. How can I access these from a Gradle script? There is an arguments input (that I guess I would use something like variable=${bamboo.variable} in there, but I cant work out how to get them to go through to the script (at the moment just doing something like prinln varible to get them out). How can I do this?
As far as I know, Bamboo exports all it's variable into the build environment. In that case, you can get any variable within the script as follows:
System.getenv('bamboo.variable')
Alternatively, you may pass it into the build as build script parameter, like so:
-Pvariable=${bamboo.variable}
and then you can get it within a script as a project property:
println variable
I wanted to know how can I set an variable from shell job available in pentaho kettle, which can be accessible by further Jobs(Simple evaluation) in the workflow.
I am trying to create a workflow where I have a start element which would trigger as shelljob to check the folder presence, if the folder is present then set one variable. The next job is Simple evaluation which needs to check if the variable(Set by shell job) is true that proceed with the workflow or terminate the workflow.
Start-->ShellJob(check folder created and set variable)-->SimpleEvaluation Job.
--MIK
Good question. I'm not aware of such capability, as the "Execute a shell script..." step isn't designed to be a data pipeline. Furthermore, what values should/can a script return to you? Is it the result of an echo? A shell script could essentially be anything. I would say there's a reason why there is no built-in functionality for that in PDI.
Having said that, what you could do is something like this:
Execute a script, at the end of it write the variables into a text file on the file system
Create a sub-transformation that reads the variables from the file you've written in the shell script step, and then stores it/them in global scope variable
Evaluate the variables in the job
It may seem a bit cumbersome, but it should do the job for you, since you're asking to use the Shell Script step in a way it's not really designed to be used.
Here's an example of a high-level implementation (implementation of the sub-transformation should be very simple):
I hope it helps.
I am using the Intellij 11.1.5. We are a large team, and have a pretty complex project setup. so we've made a template and when someone needs a new project set up, we just clone it and she is pretty much ready to go. One other thing i would like to automate is the creation of run configurations. One such configuration starts a custom bat file that requires a parameter representing a path that is user specific. I wanted to know if can store that value as a path variable specific to each project. Maybe somewhere in the .idea folder in my project. I know that Intellij stores it in its .IntelliJIdea11\config\options\path.macros.xml file, but is there a way to tweak that?
Any other idea that would allow me to locally store a parameter passed to the run config script would be usefull.
Thanks
I'm afraid you can't do it in IDEA, but you can use some environment variable directly in the .bat file instead of using the parameter (or rewrite the batch script to detect this value automatically, if possible). Instruct your users to define this environment variable.
IDEA Path variables are global and cannot be made project specific.
We have a standard MSBuild project file that is used for our different deployment stages (pre-stage, stage, live, etc). Since each deployment stage is performed on a different server we introduced a server parameter called $SourceDatabaseServer and used this extensively in each of the targets inside the project file. Note: This database server name could be different from the server name on which the build is run.
To assist us with the customization of this parameter, we created a response file for each deployment stage and subsequently defined a value for this parameter in the response file, e.g. /p:SourceDatabaseServer=SRC_DB_NAME.
This worked fine, until we created a new deployment stage in which this value had to be the current computer name. So we thought by using the $(COMPUTERNAME) reserved property in the response file (/p:SourceDatabaseServer=$(COMPUTERNAME)), this would do the trick, but it seems like this value is interpreted literally by MSBuild, and we consequently get an error that server $(ComputerName) could not be found.
Interestingly, when the $(COMPUTERNAME) property is used directly in the proj file it works, but as stated above, we do not necessarily want to use the computer name in all the cases.
Is there a way to still use the $(COMPUTERNAME) property in the response file and get MSBuild to interpret this correctly?
What if you use %COMPUTERNAME%?
$(VAR) is the syntax for variable expansion when you're "inside" the MSBuild system, but coming from the outside, I believe you'd have to use the shell environment variable expansion syntax, %VAR%.