I am writing a maven plugin. I need the following functionality. So that my plugin can read properties from the properties section of the project file that my plugin will use. Is it real?
Primary goal:
The data that is needed for my plugin to work can be passed through the <-Configuration-> section, but I need the ability to pass parameters through the command line when calling my plugin.
Unfortunately, the same parameter will be specified in both the <-configuration-> section and on the command line, then the maven, in priority, will take values from the <-configuration-> set.
I need that, even if the value is specified in the <-configuration-> section, it will return the value that will be passed on the command line.
I need to be able to pass a username and password to my test suite when I run it. I'm not sure what's the best way to do so.
My project runs with Cucumber on Java, using Maven.
If it was just a java project I'd probably have a main method where I could get the parameters passed when project is executed. But since there's cucumber here, with its feature files and then some java classes for test implementation, I'm not sure how to do it.
Suppose that you build your project using
mvn test
and now you want to add a user name and a password to the execution.
One way of doing this is
mvn test -DuserName=foo -Dpassword=bar
Where the user name is foo and the password bar.
Next task is to pick up the values in your code. This is done by reading system properties:
String userName = System.getProperty("userName");
String password = System.getProperty("password");
userName and password will be null if the values isn't passed properly.
We have created maven archetype for users to generate project. Now we want a certain archetype property to be set using the user input. Can somebody point out a way by which we can prompt the user for input during project generation and use the input to set the property?
Make use of a property file, visit http://maven.apache.org/archetype/maven-archetype-plugin/examples/create-with-property-file.html to see how this works.
I'm looking for a way to attach some specific build parameter to a scheduled trigger.
The idea is that we are continuously building debug versions of our products. Our nightly build has to be a release build, though. The build configurations for most of our projects is absolutely the same. It even has a configuration parameter, already. So all I would need is a trigger which allows for specifying an override for a single build parameter. That would cut the build configurations to maintain by half.
Is there a way to achieve this?
Not right now, you can follow this issue.
The approach I use is to create a "Deploy :: Dev D1 :: Run all integration tests" build. I then create a build trigger on each integration service build.
I create a parameter called "env:OctopusEnvironment" for integration service build. Set the value to be empty. I like to use prompt and display:
select display='prompt' label='OctopusEnvironment' data_13='Production' data_12='CI' data_11='Local - Hassan' data_10='Local - Mustafa' description='OctopusEnvironment' data_02='Test T1' data_01='Dev D1' data_04='Local - Taliesin' data_03='Continuous Deployment CI 1' data_06='Local - Paulius' data_05='Local - Ravi' data_08='Local - Venkata' data_07='Local - Marko' data_09='Local - Ivan'
In each integration service build I add this powershell step:
$octopusEnvironment = ($env:OctopusEnvironment).Trim()
Write-Host "Octopus environment = '$octopusEnvironment'"
if ($octopusEnvironment.Length -lt 1) {
Write-Host "Auto detecting octopus environment"
$trigger = '%teamcity.build.triggeredBy%' -split '::'
if ($trigger.Length -gt 2){
$environment = $trigger[1].Trim()
Write-Host "##teamcity[setParameter name='env.OctopusEnvironment' value='$environment']"
}
}
So now I can run the integration test via a trigger and when I run it directly it will prompt me on which environment to run integration test against.
I was stuck with the same problem and voted for the issue mentioned by Evgeny. One solution we thought, as mentioned sergiussergius, was to add a final step in the build-steps sequence to trigger manually the next build-configuration by passing custom-build parameters using the REST API. But in this case, we are loosing the build-chain information.
Using TeamCity 9.x, trying some stuff on the REST API, I could implement a solution who makes it possible to retrieve the triggering (ancestor) build and its parameters from the triggered (child) build.
The first thing we do is getting the current build using the environment variables set by TeamCity:
https://<host>/httpAuth/app/rest/builds/number:<env.BUILD_NUMBER>,buildType:(name:<env.TEAMCITY_BUILDCONF_NAME>,project:<env.TEAMCITY_PROJECT_NAME>)
In the response from the REST API, we have a /build/triggered tag which contains information about the trigger. It looks like this
<triggered type="unknown" details="##triggeredByBuildType='<triggering-build-configuration-internalId>' triggeredByBuild='<triggering-build-number>'" date="20160105T190642+0700"/>
The looks like btxxx for us.
From it, we can access the triggering-build (ancestor) using the following request to the REST API:
https://<host>/httpAuth/app/rest/builds/number:<triggering-build-number>'4,buildType:(internalId:<triggering-build-configuration-internalId>1,project:name:<env.TEAMCITY_PROJECT_NAME>)
from the response, we can get the ancestor-build's parameters values, and set it in the current build using:
echo "##teamcity[setParameter name='env.ENV_AAA' value='aaaaaaaaaa']")
Notes:
this post reference TeamCity version 7.X. I did this using TeamCity version 9.X, and could not try it with a previous version. I don't know if the REST API calls mentioned in my post are similar in the previous versions.
In this solution, the ancestor's build-configuration (the one who trigger the build) and the child's build-configuration (the one triggered) are in the same project. I did not do the test using build-configurations in 2 different projects: I would expect the "trigger" tag to provide information about the ancestor's project. It would be nice if someone could do the test.
I hope this solution may help!
This is not a general solution, but in certain cases (for example if you want to determine whether the build was started by a schedule trigger or some other method), a workaround is to examine the predefined parameter teamcity.build.triggeredBy.
This parameter is set to the same string that is shown on the build's overview page next to the label "Triggered by:". For example, "Schedule Trigger", "Git", or a user's full name. (There is also a teamcity.build.triggeredBy.username parameter, but it is only set in the latter case).
The limitation of this approach is that you cannot, for example, distinguish between two separate schedule triggers defined for the same build configuration. But in that case you could resort to examining the current time as well.
I added request to last build step
curl -i -u "%login%:%pass%" -H "Content-type: text/plain" -X PUT -d "v1" http://tc.server/httpAuth/app/rest/buildTypes/id:%buildConfigurationId%/parameters/env.%SOME_PARAMETER%
http://confluence.jetbrains.com/display/TCD8/REST+API
We're going to trigger hudson builds from powershell using curl and the build url:
http://hudson:port/job/build?parameters...
now I'm wondering if we can somehow pass a parameter that will add to the "triggered by" description for the builds started by our scripts?
I don't know how to edit the "triggered by" info on the build summary page without writing your own Hudson plugin. However, I like to add my own sections and badges to the build summary page with the Groovy Postbuild Plugin. In your case, you could use curl to pass an extra parameter string when starting your Hudson job. Then, you could have the Groovy Postbuild Plugin read that parameter and create a new icon + text string on your job's build summary page. That info could be the custom "triggered by" description that you'd like.