Within the Jenkins Auto-Configuration guide, we’ve created a special dedicated add-on for the automated setup of this integration tool. However, in order to make sure everything was defined correctly and not a single configuration point was missed, we recommend to test your code before the appliance.
For this purpose, you need to create a separate environment with the same topology your add-on is being created for (i.e. Tomcat 7 with Jenkins app deployed in our case) and to run the adjustment commands directly inside your compute node’s container using SSH.
Let’s follow the steps we’ve considered during the add-on creation, namely:
- uploading the scripts, required for setting the jobs
- configuring Jenkins itself
- creating and linking jobs to automatically lead an application through the lifecycle
Proceeding with the above suggested flow, we’ll check the results of the executed commands and track the changes, occurred inside a container.
- In the first piece of code, we create a dedicated projects’ folder and fill it with the files, required for the further Jenkins jobs setting:
mkdir /opt/tomcat/demo <span class="Apple-tab-span">cd /opt/tomcat/demo echo ENV_NAME= > /opt/tomcat/demo/variables curl -fsSL file_url -o install.sh curl -fsSL file_url -o transfer.sh curl -fsSL file_url -o migrate.sh curl -fsSL file_url -o runtest.sh
Let’s check it via SSH, as we’ve appointed at the beginning.
As you can see, after performing the above listed commands, our newly created demo folder includes all 4 scripts we’ve uploaded to it and the variables file for the further storing of the automatically generated name for the environments with your app’s different versions.
- The second part of the code will remove all the existing (i.e. that are installed automatically during the initial tool deployment) Jenkins plugins in order to prevent incompatibility issues or mismatch of their versions with the upcoming configurations. After that, we move to the main .jenkins directory.
rm -rf /opt/tomcat/temp/.jenkins/plugins cd /opt/tomcat/temp/.jenkins/
In order to check these strings and to ensure the plugins folder is really removed, execute a listing command before and after running them.
As you can see, for the first time directory with Jenkins plugins exists (circled on the image above), and for the second one - is absent.
- Now, we need to add the necessary plugins and configuration files to the Jenkins integrator instead of the deleted ones, by uploading and extracting the appropriate plugins.zip archive.
curl -fsSL file_url -o plugins.zip unzip -o plugins.zip >/dev/null 2>&1
As a result of these commands’ execution via terminal, you’ll see the uploaded archive (highlighted with red) with the extracted files at a new plugins folder alongside.
- The next section of code uploads and extracts another required package (jobs.zip), that includes the list and prescriptions for the required Jenkins jobs’ configuration.
curl -fsSL file_url -o jobs.zip unzip -o jobs.zip >/dev/null 2>&1
Comparing to the previous step, the .jenkins folder content was enlarged with a new jobs archive and the same-named folder.
- Finally, define the restart of the server in order to apply all of the executed configs.
sudo /etc/init.d/tomcat restart >/dev/null 2>&1
Great, the last command is completed without any errors.
- Now, you can access your Jenkins server (e.g. by using the Open in browser button) to ensure all of the appointed jobs actually exist.
In such a way, you can be sure that being combined together, all add-ons’ code parts will automatically perform almost all of the required Jenkins configurations.
Thus, now you can place them within the appropriate commands section in your add-ons’ manifest - you’ll get something similar to the following:
Then just Save your new pluggable module and make it accessible via the dashboard.