devonfw shop floor 4 production line environment - Jorge-Dacal/devonfw-shop-floor GitHub Wiki
Before running any kind of Jenkins Job related to Devonfw, it is mandatory to provide our instance with the needed tools that they’re going to use. In this case, two versions of Maven: 3.3.3 and 3.3.9. If they are already installed, you can skip this step. These tools can be installed via the Jenkins’ Maven plugin or via Custom Tool.
-
Jenkins' Maven plugin
In the main Jenkins view, go to Manage Plugins inside of Manage Jenkins, and look for the Maven Integration plugin. If it’s not installed, do it.
-
Maven as a Custom Tool
Inside of Manage Jenkins as well, go to Global Tool Configuration. Click on Custom tool, and check what it is there. It is another way of installing some tools. For example, the Angular CLI has no Jenkins plugin, so it can be installed that way.
First, install the NodeJS Plugin from the Manage Plugins section of the Jenkins management menu. Then, go to Global Tool configuration and install the LTS version of NodeJS like this:
This headless browser would let us to execute Karma tests (Angular tests) in Jenkins. As Jenkins has no plugins for it, it’s necessary to install it as a Custom Tool:
Shell Command:
if ! which google-chrome > /dev/null; then
sudo su << EOF
wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add -
echo "deb http://dl.google.com/linux/chrome/deb/ stable main" > /etc/apt/sources.list.d/google-chrome.list
apt-get update && apt-get -y install google-chrome-stable
EOF
fiTool Home:
/opt/chrome
Go to Credentials > System > Global credentials (unrestricted). You will have an Add credentials option on the left side. Click on it and specify some CI credentials that your team provides to access to Devonfw repositories. Could be something like devonfw-ci/*********.
Next step will be creating the Global Devonfw Maven Settings. They will define where Maven is going to download dependencies from. For example, if we want to have a kind of closed cycle in our CI environment, we can tell Maven to download modules only from our instance’s Nexus, or from some Artifactory instance we may have, etc.
Go to Manage Jenkins and Managed files, and click on Add a new Config. Select the option of Global Maven settings.xml and submit it.
There will be 3 parts to be configured, one for settings’ name, ID (provided) and description, another one for Server Credentials (who is going to download dependencies, usually done by a Technical user, which means some non-personal credentials) and the content itself. For example, to download from our instance’s Nexus, we can specify credentials for the Nexus in general and one particular Devon repository:
Create the mirror:
<mirror>
<id>nexus.central</id>
<mirrorOf>central</mirrorOf>
<name>central-mirror</name>
<url>[PL_INSTANCE]/nexus/content/repositories/central</url>
</mirror>Create the profile and its repositories:
<profile>
<id>devon.nexus</id>
<repositories>
<...>
<repository>
<id>devon.releases</id>
<name>Devon Releases</name>
<url>https://[PL_INSTANCE]/nexus/content/repositories/releases</url>
<releases>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
</releases>
<snapshots>
<enabled>false</enabled>
<updatePolicy>always</updatePolicy>
</snapshots>
</repository>
<...>
</profile>This configuration is the same we could have in the local Maven repository of the Devonfw distribution.
This job will push all needed Devonfw modules to install Devonfw projects’ dependencies. It will be created in Jenkins (with optional name). In this case, two projects are created: one for the current develop branch of the repository and the other for the 2.0.0 version.
Let’s go to devon_develop Job, and click Configure. In this view all Job’s settings are shown.
General (just some non-technical details about the Job)
In the Source Code Management we specify what do we want to run in Jenkins. In this case, the Devonfw’s GitHub repository in the develop branch. To access it from our PL instance, there will be necessary to set up some GitHub credentials that can actually find the repository. You may use the ones created in (2).
In the Build Environment we tell the Job which tools of the environment we are using to run all process that it’s going to execute. In this case, two versions of Maven.
Next step is defining what the devon_develop Job is actually doing. The Build step will be done by creating an Execute Shell section that will execute something like this:
This will add a <distributionManagement> section into the Devon project main pom.xml that will point to our instance’s Nexus container ( http://nexus:8081 ).
See the code here:
echo '<distributionManagement>
<repository>
<id>devon.releases</id>
<name>devon Releases</name>
<url>http://nexus:8081/nexus/content/repositories/releases/</url>
</repository>
<snapshotRepository>
<id>devon.artifactory</id>
<name>devon Snapshots</name>
<url>http://nexus:8081/nexus/content/repositories/snapshots/</url>
</snapshotRepository>
</distributionManagement>
</project>' > append
# Open XML structure
sed -i 's|</project>||g' pom.xml
# Close XML structure
cat append >> pom.xmlIn the same Build section, let’s Invoke top-level Maven targets. That will execute the needed Maven command to build the project and deploy all artifacts to Nexus.
In we click in the Advanced… button, we will have the chance to set up some Global Maven Settings to be used by this Jenkins Job. We choose the already created Global Devonfw Maven Settings, and we can save the Jenkins Job. Nothing more. Just build it from the Job’s main view and you’ll have all you need in your Nexus afterwards.
You are ready to run the devon_develop Jenkins Job, and check your instance’s Nexus container to see the results.
This documentation is licensed under the Creative Commons License (Attribution-NoDerivatives 4.0 International).
