Is it possible to specify build parameters ?
There is option for environment but it is not for build.
Something that will be put in command line as /p:MyParameter=MyValue
Related
I am trying to setup a Jenkins pipeline to trigger builds using gradle for multiple environments.My requirement is that the artifacts produced when I run gradlew clean build should produce artifacts with name indicating the environment for which the pipeline was run. Example my-application-dev.jar
The value of the environment would be selected by the user when build will be triggered.
What is the optimal way to achieve this ? Does build allow to configure any such property via command line or do I need to define a task in my build.gradle and define properties within that task for which I will pass value from command line
There are basically two ways.
The first one is to pass these naming-relevant pieces of information to the gradlew process, e.g. via -D or -P properties.
Then you need the Gradle build to be aware of these parameters and craft the artifact names it produces accordingly.
The second one is arguably better and more contained. You simply rename the artifacts produced by the gradlew command after it completes, in the Jenkinsfile. This works well if the pipeline decides what to do with these artifacts (e.g. publish to a repository) as opposed to the gradle script doing it (in which case you would most likely be better off using the first method).
I'd like to select between different Gradle tasks to use when building an Android app on Jenkins.
For example, if an env variable is equal to "Full" the Gradle tasks that will be used are:
clean
build
assembleDebug
assembleDebugAndroidTest
If the env variable is equal to "Not Full", the Gradle tasks that will be used are:
clean
build
I know I should used the Conditional BuildStep plugin but the documentation is a bit foggy.
Thanks!
Use the Strings match settings from the Conditional Step. Assuming your env variable is named $YOUR_ENV_VAR :
For the Full case
For the Not Full case
How can I alter the default arguments passed to the mvn executables executed on a Windows system without modifying each installation or manually creating alternative startup scripts (or otherwise "hard-coding" my preferences in a non-portable way)? To be clear, I am not open to external methods like a console alias or using a shortcut or filesystem link. I am asking for a Maven-specific portable way to describe the default startup arguments for all Maven executions on my Windows machine.
Much like MAVEN_OPTS allows you to pass command line arguments to the JVM used to run Maven, MAVEN_CMD_LINE_ARGS is an environmental variable that allows you to pass command line arguments directly to Maven itself (but only on Windows). Unlike modifying files and settings at the level of an individual Maven installation or project (via settings.xml or maven.config for instance), MAVEN_CMD_LINE_ARGS allows you to pass command line arguments to any Maven installation spun up using the provided startup scripts (on Windows the scripts are "mvn.cmd" and "mvnDebug.cmd").
As an example, on my Windows development computer I have set MVN_CMD_LINE_ARGS to
--show-version --global-settings %M2_CONF%\settings.xml --global-toolchains %M2_CONF%\toolchains.xml --define settings.security=%M2_CONF%\security-settings.xml --fail-fast --update-snapshots --strict-checksums --define maven.artifact.threads=8.
Instead of having to place an alias or create my own startup script I simply can use this builtin method to achieve my goal of standardized cross-installation configurations. With MVN_CMD_LINE_ARGS set to that value, executing
mvn
on the command line is actually like executing
mvn --show-version --global-settings %M2_CONF%\settings.xml --global-toolchains %M2_CONF%\toolchains.xml --define settings.security=%M2_CONF%\security-settings.xml --fail-fast --update-snapshots --strict-checksums --define maven.artifact.threads=8.
Now, notice I said that I believe this only functions on Windows. While the Linux Bash scripts include an export of a variable called MVN_CMD_LINE_ARGS they do not then pass it to the mvn executable as an argument. The result of this is that on both Windows and Linux you can use MVN_CMD_LINE_ARGS from after the execution to determine what arguments were used to call mvn, but only on Windows can you use MVN_CMD_LINE_ARGS to instruct which arguments will be used to call mvn. From what I can tell though, this behavior may not be intended, so I would not recommend using this in a critical manner. It seems there is a project specific way to configure the mvn execution arguements via placing them into a "./.mvn/maven.config" file within the projects directory structure.
I'm using TeamCity 8 to run a msbuild script.
I thought TeamCity would set an environment variable or msbuild property with the vcs root url. But I can't find it.
I've tried running the script with /v:diag to get more info, and still can't find any property.
Can I get the url from Teamcity or do I have to run something like svn.exe info?
Here is what I'm currently doing.
TeamCity does have the variable, it's named %vcsroot.url%, but it's available to scrips as default.
To make it available in the msbuild script (and other types as well).
Goto project settings -> Parameters -> Add new parameter
Name: system.vcsroot.url
Kind: System property
Value: %vcsroot.url%
And you have property as $(vcsroot_url) in msbuild
I'm trying to set/change a build parameter from build 1 to be used in build 2.
In build 1 I have a build step that sets a configuration parameter like this:
echo "##teamcity[setParameter name='ENVIRONMENT' value='%Target environment%']"
And in a build step on build 2, I want to use this environment variable in a rake task by
specifying %ENVIRONMENT%
The problem I have is that the configuration parameter is not visible in build 2. I have surely missed something essential.
I have also tried with env variables but that seems like the wrong approach as this is just configuration variables which is not needed in a build script.
Any clues?
Thanks
You can publish an artifact with the value you want in build 1, introduce an artifact dependency from build 2 to build 1, and in the first step of build 2 transform that artifact into a configuration value again for the other steps in build 2 by using the echo (or better Write-Host) statement you mentioned.
You can solve this in the same way I did for:
Is it possible to permanently update the value of a TeamCity build parameter as a result of a custom run?
Build 1 can update a variable which is being used in build 2 rather than build 2 trying to read a parameter in build 1.
Download and install CURL on build agent:
Add a command line step to build 1:
curl -v --request PUT -d "%Target environment%" --Header "Content-Type: text/plain" http://username:password#servername:8080/httpAuth/app/rest/projects/Build2Project/parameters/ENVIRONMENT
This updates the value of a parameter on a project, but you can use the REST API to update it on a particular build configuration if you prefer.
All REST.API documentation for TeamCity v8 can be found on their website
You can reference MyVariable variable which you set in Build configuration 1 in a script in Build configuration X such way: %dep.BuildConfiguration1Id.MyVariable%