At the Manual Judgement stage we were hoping we could enter a value, continue and pass that value onto Jenkins with "${#judgment("Manual Judgment")}". We can pass the predefined option but can't enter a new one. Is there a way of getting this to work or an alternative method?
One way to achieve this is by using pipeline parameters.
In configuration stage of the pipeline, add a parameter (say Name="jenkins") and configure the parameter's options (like default value, required or not)
Before the manual judgment step, create a Evaluate Variables stage. In the stage configuration, create a variable named "jenkins" with the value ${parameters.jenkins}
In manual judgment's options, add the variable ${jenkins}
Now, during the manual judgment stage, it would show an option with the value provided to the pipeline.
You could also join Spinnaker's slack here: https://join.spinnaker.io/
Related
I have defined in my bamboo plan a variable (BAMBOO_TEST_VAR) that I'd like to reuse in a particular script but I can't seem to figure out how to make it visible to that script.
If I just reference that variable from the script it merely prints the variable as empty.
27-Oct-2020 23:34:00 TEST JOB
27-Oct-2020 23:34:00 bamboo.shortJobName =
27-Oct-2020 23:34:00 BAMBOO_TEST_VAR=
And if I provide it as input to the Environment variables field it just renders with the value I give in that field taken as a literal, not to the plan variable I was hoping it would evaluate to.
27-Oct-2020 23:36:57 TEST JOB
27-Oct-2020 23:36:57 bamboo.shortJobName =
27-Oct-2020 23:36:57 BAMBOO_TEST_VAR=$BAMBOO_TEST_VAR
How can I reference the plan's environment variable directly from a script task without passing it down through arguments or something of the sort. What aspect or bamboo detail am I ignorant of that would have informed me that what I'm attempting is not possible or not supported because of reason XYZ?
So the trouble was I didn't scope the variable appropriately. What did it in the end was
${bamboo.BAMBOO_TEST_VAR}
Turns out if I slowed down and looked at the bamboo page more carefully I would have noted the help breadcrumbs they left around. Copying that help text here, emphasis mine:
Variables substitute values in your task configuration and inline scripts. If a variable name contains any reference to a password, like "password", "sshKey", "secret", or "passphrase", its value will be masked with "********".
For tasks configuration fields, use the syntax ${bamboo.myvariablename}.
I have environmental variable called ENV, which holds the DEV,QA OR PROD region as value. When the server.xml loaded it includes the corresponding db configuration using this variable. For ex: db-config-${env.GAH_ENV}.xml
I would like to pass the same value to the batch job xml as a job parameter or properties to any of the class. How Can I do that.
below code snippet not working
<property name="environment" value="${env.GAH_ENV}"/>
The short answer is that using a batch property may not be a good solution and you might consider something else like MicroProfile's #ConfigProperty.
The reason is there's not a built-in way to access environmental variables through JSL substitution. There is also not a convenient way for one artifact to set a property value to be used by a second artifact running later within the job execution.
In the special case that you are starting the job from within the same JVM it will execute, of course, you could pass the env var value as a job parameter.
But in the general case, if you can change the Java code and you don't really need a batch property I would use a MicroProfile Config property instead, injected via #Inject #ConfigProperty.
By doing so you lose the batch-specific substitution precedence, including the override available via job parameters passed with the submit/start. You also give up the ability to use this property in other JSL substitutions (to "compose" its value into other batch properties via other substitutions).
But you at least get a property with its own various levels of precedence/override (e.g. server config, env var, microprofile-config.properties), which is more flexible than just always reading the env var via System.getenv( ).
This is certainly an area to consider for the next version of the (now-Jakarta) Batch spec.
Using set variables step in pentaho, I have defined a variable and the scope is set to "valid in the Java virtual machine", but it is not replacing in one of the sql's used in the table input step.
Table input step is checked with option "replace variables in script". But the same variable when I placed in kettle.properties file, it is working. Pentaho job available in the repository and running from Linux box
Could anyone please share your thoughts?
You can-not set the parameter and use it in the same transformation, because it executes all the steps parallelly.
Logic-wise correct approach is first set the variable and get the variable in next transformation and further use or replace in respected steps.
As Working Hard.. says, you can not use a parameter in the same transformation, you have to use another transformation after setting the variables.
I have a simple tfs-2010 build definition using the default process template. In it I defined the Build Number Format using $(BuildID) to define part of the computed field. This works and I can see what BuildID's value is.
Now I try to pass the BuildID property to MSBuild as an argument:
/p:SomeProperty=$(BuildID)
However when I look at the build log I see SomeProperty literally equals $(BuildID) rather then the value of BuildID.
What am I missing?
Update for clarity: What I'm asking is how to reference as a Build Process Parameter in the Build Definition. For example Build Number Format has a default expression of $(BuildDefinitionName)_$(Date:yyyyMMdd)$(Rev:.r)
You need to use a VB.NET expression. For example:
String.Format("/p:SomeProperty={0}", BuildDetail.BuildNumber)
The Build Number tokens, e.g. $(BuildDefinitionName), are specific to the Build Number Format process parameter. They aren't tokens that you can use anywhere else in the build process. Most are available in the BuildDetail object or from the environment. The Build Id is a bit of a special case, however. It comes from the identity column of the builds table and isn't directly exposed in our public API. You could extract it from the BuildNumber, like this:
BuildDetail.BuildNumber.Substring(BuildDetail.BuildNumber.LastIndexOf('/') + 1)
Note that you would need to do this in the XAML directly rather than putting a VB expression into the build process parameter editor GUI. That's because those values just get passed through as literal strings.
Is there anyway to specify more than one MergeSection value for the MSBuild LINK task? (The MergeSection param is the same as the /merge param for link.exe)
http://msdn.microsoft.com/en-us/library/ee862471.aspx
When calling link.exe you can specify more than one /merge value, but that doesn't seem possible with the MergeSection parameter.
So far the only way I can see to make this work is by using the AddtionalOptions param, but I'm hoping there's a better way to implement this parameter.
Thanks
I think you may have to use AdditionalOptions.
In the Link task the MergeSections property is a string value, not an array, so you can only set one string. Link.exe does not seem to allow you to pass multiple pairs in one command line parameter, you must specify a separate MERGE command line parameter for each pair. The Visual Studio property page only allows a single string for the MergeSections property.