Have a GitHub plug-in in IntelliJ. It knows the branch that is being worked on.
How would you get that branch name and add it into the system properties used when launching a server in the IDE?
This would be the equivalent of something like:
-Dthevariableforbranchnumber=${some.branch.number}
Support for variables in the parameters of the run/debug configurations was added recently, but there is no variable for the branch number.
There is also a related request to add branch to the live templates.
You are welcome to submit a new request at https://youtrack.jetbrains.com/issues/IDEA to provide a variable with the VCS branch for the run configuration.
Still not clear how it will work if the project has multiple VCS roots with different branches.
Related
I am developing new pipeline within Jenkinsfile using intelliJ.
When I was using jenkins 1 with pipeline-dsl plugin I could go into the source code and see how DSL was actually implemented in org.jenkins-ci.plugins:job-dsl-core. I would like to have the same ability with Jenkinsfile.
Can I somehow connect Jenkinsfile DSL and intellij to have there proper code completion and sourcecode insight?
In order to have access to the sourcecode for the Pipeline Plugin suite of plugins when working on ANY Jenkins pipeline script, whether global or otherwise, you will have to include the necessary libraries as dependencies.
I'm working on my current global pipeline library.
Here adding the CPS library via "Project Structure" menu item:
Go to Libraries
Click the add button and select "From Maven..."
Type in the correct GAV (in this case com.cloudbees:groovy-cps:1.9)
Click the magnifying glass button - IntelliJ will search Maven Central (and whatever other repos you've configured in the Maven IntelliJ configuration or via your settings.xml) and download them to an your local cache.
Rinse and repeat until you've got all the dependencies you need.
When you're done, it should look something like this:
I found that the minimum useful were:
com.cloudbees:groovy-cps:1.9
org.jenkins-ci.plugins.workflow:workflow-api:2.+
Have you tried this approach yet?
Background:
I've been using Eclipse for a while and am trying out Intellij now.
I checked out my project from Git (via Intellij) and recognized it as a gradle project. Its created the WAR(& the exploded WAR) all of which are fine.
Question:
When I was using Eclipse, I used the command:
gradlew -Penv=Development :my_webapp:assemble
This used to do a few things including creating a environment.properties file that my dev specific env could use (for selecting database instances etc) based off of -Penv=Development...I'd like the Intellij gradle build to do the same... What's a way to configure Intellij's gradle process to do these custom things or provide same features as provided by this specific command line tool (Note - the code for this is already written in build.gradle file)...
I looked at some of Intellij's docs, but could not find an answer to this.
EDIT:
I've found the solution, for anyone interested - read on...
Seeking guidance from #Stanislav, I was able to add the property as follows:
In your server's run configuration (Run/Debug Configuration -->Your server's config(Jetty etc), there is a section called Before launch, which should have Make/Build Gradle already included
Hit the + sign -->Run Gradle Task --> Select your gradle project (i.e. the web app) --> Select the task (most likely loadEnvironmentConfiguration) --> set the script parameters such as -Penv=Development, hit OK
Move this to before the Build Gradle function (by using the up arrow - to the right of + sign you hit in step 2)
It seems, that you need to create your specific run or debug configuration. You can read about it in official IntelliJ Idea help. All you need, is to modify your configuration for the task you need, by providing the argument -Penv=Development, since it is running with gradle.
You may also need to define Gradle instance, which will be used via settings, if the defaul wrapper wont work for you. You can find almost all you need in the the official help.
We moved from Hudson to Jenkins and are using StarTeam for version control.
Now according to this site (https://wiki.jenkins-ci.org/pages/viewpage.action?pageId=47480884) there are no global settings to setup StarTeam config.
So we have to specify the StarTeam configuration manually per project (Jenkins Home/[myProject]/configure 'Source Code Management Section')
Certain properties will always be the same like the HostName and the Port #. Now if we were ever to change the StarTeam server we will have to go to every single project and update it again.
Is there a way that we can specify this in a variable and use it in every project?
We tried to create a global environment var (Jenkins Home/Manage Jenkins/Configure System in the 'Global Properties' section).
And then under the project I am trying to configure I have
But when it is building it has difficulty connection to server ${STARTEAM_SERVER}. Have anyone used this before?
Sadly, the Starteam Jenkins plugin doesn’t understand parameterized values. You have to enter the IP or machine name instead.
Raise issue in Jenkins if you want but I don't think anyone is maintaining the Starteam plugin now.
I do not know if it works, but you can try a properties.file.
Content of the file which constains the script:
echo "STARTTEAM_SERVER=`MyServerNameGoesHere`"> env.properties
Path of the properties file:
env.properties
Source code Management (StartTeam)
echo"$STARTTEAM_SERVER"
Something like this works for the build, maybe here works too.
The answer from ABose was correct at the time, but might be worth another look. As of June 24, Borland closed a vote on their User Voice site. I believe they have finally taken an active role in contributing to the Jenkins plugin. Not sure if it is the same base or if they have written their own plugin. I was in conversation with them on this back in 2012, and it seems they may have gotten this going again. Here's a link: http://borland.uservoice.com/forums/143611-starteam-feature-requests/suggestions/2466059-expanded-build-tool-integrations.
You might try contacting Borland Support to find out more, and bring this feature suggestion to their attention.
I'm currently creating a custom Maven enforcer rule, and for its purpose, I need to know the URL of the SCM (Subversion, Git...) used for the given job, i.e. where the sources were just checkouted by the Jenkins job.
Is there a way to get that information?
I had a look on the parameters set in system environment by Jenkins, but none of them give me the full SCM url used by the job. Also, the API (i.e. http://jenkins-server/job/my-job/api/xml) does not contain this information.
I know that there is a <scm><connection> tag in the pom.xml, but this information may not be reliable.
Thanks.
These values are set by the SCM implementation. To find out which environment variables actually exist in your build, you can use the EnvInject plugin.
For Subversion, you can use the environment variable SVN_URL (if it's one URL only), or SVN_URL_n, n being a number (if it's multiple URLs) as described here.
You could also use the System Groovy build step in the Groovy plugin to access the Jenkins object tree directly and e.g. write this information to a file. Note that accessing internals in prone to breaking in updates, and prone to breaking Jenkins if you're not careful.
I have a project that need to be deployed into multiple environments (prod, test, dev). The main differences mainly consist in configuration properties/files.
My idea was to use profiles and overlays to copy/configure the specialized output. But I'm stuck into if I have to generate multiple artifacts with specialized classifiers (ex: "my-app-1.0-prod.zip/jar", "my-app-1.0-dev.zip/jar") or should I create multiple projects, one project for every environment ?!
Should I use maven-assembly-plugin to generate multiple artifacts for every environment ?
Anyway, I'll need to generate all them at once so it seams that the profiles does not fit ... still puzzled :(
Any hints/examples/links will be more than welcomed.
As a side issue, I'm also wondering how to achieve this in a CI Hudson/Bamboo to generate and deploy these generated artifacts for all the environments, to their proper servers (ex: using SCP Hudson plugin) ?
I prefer to package configuration files separately from the application. This allows you to run the EXACT same application and supply the configuration at run time. It also allows you to generate configuration files after the fact for an environment you didn't know you would need at build time. e.g. CERT
I use the "assembly" tool to zip up each domain's config files into named files.
I would use the version element (like 1.0-SNAPSHOT, 1.0-UAT, 1.0-PROD) and thus tags/branches at the VCS level in combination with profiles (for environments specific things like machines names, user name passwords, etc), to build the various artifacts.
We implemented a m2 plugin to build the final .properties using the following approach:
The common, environment-unaware settings are read from common.properties.
The specific, environment-aware settings are read from dev.properties, test.properties or production.properties, thus overriding default values if necessary.
The final .properties files is written to disk with the Properties instance after reading the files in given order.
Such .properties file is what gets bundled depending on the target environment.
We use profiles to achieve that, but we only have the default profile - which we call "development" profile, and has configuration files on it, and we have a "release" profile, where we don't include the configuration files (so they can be properly configured when the application is installed).
I would use profiles to do it, and I would append the profile in the artifact name if you need to deploy it. I think it is somewhat similar to what Pascal had suggested, only that you will be using profiles and not versions.
PS: Another reason why we have dev/ release profiles only, is that whenever we send something for UAT or PROD, it has been released, so if there is a bug we can track down what the state of the code was when the application was released - it is easier to tag it in SVN than trying to find its state from the commit history.
I had this exact scenario last summer.
I ended up using profiles for each higher environment with classifiers. Default profile was "do no harm" development build. I had a DEV, INT, UAT, QA, and PROD profile.
I ended up defining multiple jobs within Hudson to generate the region specific artifacts.
The one thing I would have done differently was to architect the projects a bit differently so that the region specific build was outside of the modularized main project. That was it would simply pull in the lastest artifacts for each specific build rather than rebuild the entire project for each region.
In fact, when I setup the jobs, the QA and PROD jobs were always setup to build off of a tag. Clearly this is something that you would tailor to your specific workplace rules on deployment.
Try using https://github.com/khmarbaise/multienv-maven-plugin to create one main WAR and one configuration JAR for each environment.