Skip to content

Instantly share code, notes, and snippets.

@szpak
Last active January 12, 2019 16:30
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 8 You must be signed in to fork a gist
  • Save szpak/9bad17f2d9055d13ee164a6eaa5e4282 to your computer and use it in GitHub Desktop.
Save szpak/9bad17f2d9055d13ee164a6eaa5e4282 to your computer and use it in GitHub Desktop.
Continuous Integration in IT projects - user manual

User manual for CI exercises

Exercise 1. Jenkins - warm-up

1.1. GitHub project - setup

  1. Login to your GitHub account (or create one if necessary)
  2. Fork solid-soft/junit4 to your GitHub account (using Fork button)

1.2. Jenkins - setup

  1. Ensure Java 8 is used by default on your system
  • As of January 2019 higher Java versions are not officially supported
  1. Download latest Jenkins weekly release (2.157 is fine) as WAR (or installed if preferred) from https://jenkins.io/
  2. Run Jenkins from console
  • Linux/MacOS
    • start any terminal with bash/fish/zsh
    • cd <directory-where-jenkins.jar-resides>
    • java -jar jenkins.war
  • Windows (if WAR was selected)
    • start command prompt
    • cd <directory-where-jenkins.jar-resides>
    • java -jar jenkins.war
    • Hint. Jenkins home directory can be changed (if needed) by setting JENKINS_HOME variable: SET JENKINS_HOME=C:\users\foobar\.jenkins
    • Hint. Default port to listen can be changed (if needed) with --httpPort=9090 at the end of command
  1. Enter http://localhost:8080 page in modern web browser
  2. Unblock Jenkins instance
  3. Install suggested plugins
  4. Skip user creation
  5. Click "Start using Jenkins"
  6. Shutdown Jenkins from console (CTRL-C)
  7. Edit $JENKINS_HOME/config.xml file changing <useSecurity>true</useSecurity> to false
  8. Start Jenkins (from console)
  9. Ensure your Jenkins is in English - that makes following this manual easier
  • Locale plugin may be useful if your system language is different

1.3. Jenkins - simple project build

  1. Enter http://localhost:8080 page in web browser
  2. Create new "Freestyle project" named "junit4"
  3. Configure source code repository to your GitHub (your fork) and add Maven/Gradle execution step
  • Q. What will be the most suitable task(s) to execute?
  • Hint. Use HTTPS to clone Git repository. URL can be obtained using green Clone or download button on your forked project webpage: https://github.com/YOUR-GITHUB-USERNAME/junit4
  • Hint. Use Source Code Management -> Git instead of General -> GitHub project to configure Git
  • Hint. Having problem with fetching Git repo? Ensure you have Git client installed.
  • Hint. Do not configure SCM polling to not exceed anonymous user rate limits
  • Hint. No having Maven installed? Use mavenWrapper branch and switch build step to Execute shell and ./mvnw clean package (Linux) or Execute Windows batch command with mvnw.cmd clean package (Windows) instead of Maven step.
  1. Configure publishing JUnit test result report (see "Post-build action" section)
  • Ensure report is visible on project page
  • Hint. For Maven projects JUnit reports are placed by default in **/target/surefire-reports/*.xml. For Gradle projects in **/build/test-results/**/*.xml
  • Hint. Have you got test failure? How it is reported? You can (optionally) fix or disable that test to make the build green (or blue)

Extra tasks

  1. Configure mechanism to abort build if stuck (appropriate plugin should be already installed)
  • Q. What time-out strategy would you use?
  • Q. In what situations that plugin can be useful?
  1. Configure displaying timestamp in console output
  • Q. When could it be handy?
  1. Q. What would be needed to test build also with other Java version?

Exercise 2. Jenkins - job view tuning

  1. Execute sample project a few times in the way providing successful, unstable and failed runs
  • Q. Can this information be presented in more compact way, providing place for other useful data?
  1. Rework job view to have (among others):
  • compact status column
  • last tests result
  • number of builds
  • previously used executor name
  • cron trigger
  • extra buttons/actions/columns you find useful
  • Hint. Use provided screenshot as inspiration (however, you view can be different)
  • Hint. New view can be added using + sign next to existing view name
  • Hint. Install selected plugins from provided list to get extra features - Jenkins -> Manage Jenkins -> Manage Plugins (not all are required)
  • Hint. Some plugins are not on list. Find them manually using https://plugins.jenkins.io/
  • Hint. Default view cannot be edited - create new list view and set it as default

Extra tasks

  1. Do not limit yourself with provided list of plugins - explore 1000+ Jenkins plugins available
  • Try to find features that would be useful in job daily Jenkins use

List of useful plugins

Must-have plugins
Useful in some cases plugins

Exercise 3. Travis

  1. solid-soft/junit4 should be already forked to your GitHub account after Jenkins exercise
  2. Sign in to Travis CI with your GitHub account
  3. Enable Travis for that repository (re-sync repositories in Travis if needed)
  4. Add .travis.yml to your project and configure it
  • Build project with Oracle JDK 8
  • Hint. Leverage Travis getting started instruction for Java projects
  • Hint. Came across issue with too old Maven version? Use Maven wrapper which is already configured in project (already available in mavenWrapper branch - just merge it).
    • Q: What the project tries to build twice?
    • Hint. Default implementation of Travis step can be disabled/overridden with stepName: true
  • Q. How project build time on Travis compares to that on local Jenkins?
  • Q. What method of configuration do you prefer?

Extra tasks

  1. Build project with both Oracle JDK 8 and OpenJDK 7
  2. Create some PR to your project fork (not to project in my repository!)
  • Q. What is needed to enable PR building in Travis?
  1. Experiment with Gradle/Maven wrapper and/or dependencies caching
  • Hint. Add site:site to tasks list before enabling caching to increase number of dependencies to download.
  • Q. What was the impact on project build time?
  • Q. Is there something what forces cache to be rebuilt even if there are no changes are made to dependencies?
  1. How to get detailed information about test failures?

Exercise 4. Automated testing

  1. Follow instructions available in test projects itself.

Exercise 5. SonarQube

5.1. SonarQube - setup

  1. Download latest SonarQube version (6.5 is fine) from https://www.sonarqube.org/
  2. Unzip it somewhere
  3. Run Sonar in console mode
  • Linux
    • start any terminal with bash/fish/zsh
    • cd <directory-with-unzipped-sonar>/bin/linux-x86-64
    • ./sonar.sh console
  • Windows
    • start command prompt
    • cd <directory-with-unzipped-sonar>/bin/windows-x86-64
    • StartSonar.bat
  1. Enter http://localhost:9000 page in web browser

5.2. SonarQube - simple analysis

  1. Run analysis manually from Maven (in JUnit4 directory from previous exercises)
  • mvn package (to provide compiled sources)
  • mvn sonar:sonar (or use mvnw.cmd if needed)
  • Q. There is no Sonar configuration in JUnit4 project. Why execution succeed?
  1. Find the execution results in Sonar server
  2. Explore "Issues" view
  • Q. Have you find any "real" issues or places to improve?
  • Play with keyboard navigation and shortcuts available in Sonar (press ? to see related help)
  1. Find some false positive(s) and mark it.
  • Hint. Login as Administrator (admin/a***n) to be able to modify issues
  1. Add some artificial issues in code
  • If hopeless, add 3 lines with if (1.0d == 1.0d) {} in TestSuite class (TestSuite.java file) starting with line 146
  • Hint. To find class in IDE use CTRL-N in Idea or CTRL-SHIFT-T in Eclipse
  1. Re-run analysis
  • Q. What has changed in project view in Sonar?
  • Q. Why "Quality Gate" started to fail?
  • Q. Can "Leak Period" metric be useful in your project?

5.3. SonarLint

  1. Install SonarLint for your IDE using instruction available on project webpage: http://www.sonarlint.org/
  2. Analyze sample project
  • Q. How are issues reported?
  1. Enable connected mode and rerun analyze
  • Idea
    • CTRL-ALT-S -> SonarLint General Settings -> Add
    • CTRL-ALT-S -> SonarLint Project Settings -> Enable binding ... -> Bind to server -> SonarQube project
    • More information in official documentation
  • Eclipse
  • Q. How it affected number of reported issues?
  1. Mark some issue(s) in SonarQube as false positive or won't fix
  • Q. How are those issues reported as in your IDE by SonarLint?

5.4. Sonar and Jenkins

  1. Install SonarQube plugin for Jenkins
  • Jenkins -> Manage Jenkins -> Manage Plugins
  1. Configure your local Jenkins instance
  • Enable injecting of SonarQube server configuration into build
  • Add SonarQube server in Jenkins -> Manage Jenkins -> Configure System
  • Hint. In fact it is not needed for Sonar server in development mode running on localhost - it would be taken by default anyway - but for remote server configuration properties have to be passed - you can set server URL to http://localhost:9001 to make it fail and verify it does matter.
  1. Duplicate your old JUnit job in Jenkins (New Item -> Copy from)
  • Good name can be junit-sonar
  1. Configure your junit-sonar job to run Sonar analysis
  • Tick Prepare SonarQube Scanner environment
  • Add Maven step executing sonar:sonar task
  • Hint. Use -Dmaven.test.failure.ignore=true to finish "base" Maven step despite failing tests
  • Q. Sonar analysis can be also run with Execute SonarQube Scanner step - what is advantage of using dedicated Gradle/Maven plugin?
  1. Execute analysis
  • Hint. Execution should fail if you configured port 9001. Fix it to default 9000 and verify execution finishes successfully
  • Hint. Remember to push your changes (from local analysis section) to GitHub to make Jenkins build see them (if you need it)
  • Hint. To use Maven Wrapper (if needed in your environment) add Execute shell or Execute Windows batch command instead of Maven step.
  • Hint. When in doubt (or trouble) you can consult official plugin documentation

Exercise 6a. Jenkins as code - Configuration as Code plugin

6a.1 Configuration as Code

Outline. Mange your Jenkins configuration using YAML files

  1. Install the Configuration as Code plugin (Jenkins -> Manage Jenkins -> Plugin Manager -> Available or using the aforementioned Groovy script)
  2. Configure the following settings using $JENKINS_HOME/jenkins.yaml (or depending on your installation method $JENKINS_ROOT/jenkins.yaml):
  • Hint. Create that file if not available
  • Hint. Consult auto-generated documentation to find proper syntax (Jenkins -> Manager Jenkins -> Configuration as Code -> Documentation). Please note however, it is auto-generated and in some cases may not be fully functional.
  • Hint. When in trouble (unfortunately it is quite common - the documentation has its own limitations) ask Google or search for samples in the CasC project GitHub repositor
  • Change Jenkins System message to "Greeting from the very interesting CI training" ;)
  • Create two explicit Java installation (e.g. JAVA8 and JAVA11)
    • Hint. Use JAVA8 and JAVA8_2 if you don't have two different Java versions installed
  • Set number of executors on master to 4
  • Install the Chuck Norris plugin in the latest version
  • Hint. You should start seeing log messages from io.jenkins.plugins.casc during Jenkins initialization for some actions. Also in Jenkins -> Manager Jenkins -> Configuration as Code there should be information that configuration is loaded from a file.
  • Hint. Having trouble locating a default configuration file? Override the variable CASC_JENKINS_CONFIG
  • Hint. You may reload changes in your configuration file using the "Reload existing configuration" button (Jenkins -> Manager Jenkins -> Configuration as Code)
  • Hint. Manually verify correctness of your changes in the Jenkins (or a job) configuration

Extra tasks

  • Set Safe HTML (instead of Plain text) as Markup Formatter - useful for the Stash/GitLab PR builds visualization
  • Add GitHub credentials using your newly generated API key/token.
    • Hint. Keeping passwords/tokens plain text in a configuration file placed in a Git repository is not a good practice. For real systems use Hashicorp Vault or a similar tool, alternatively pass them as environment variable to read at runtime with e.g. $GITHUB_TOKEN.
    • Hint. Be sure to define them in GLOBAL scope not SYSTEM scope to be visible in a job
  • Play with some other settings which may be useful in your daily work.

Exercise 6. Jenkins as code - Jenkins Job DSL Plugin edition

6.1. Jenkins Job DSL - warm up

Outline. Generate simple Jenkins job completely in code

  1. Install Job DSL plugin (Jenkins -> Manage Jenkins -> Plugin Manager -> Available)
  2. Create new "FreeStyle project" named simple-inline-seed
  3. Add Job DSL script processing in Build section
  4. Select inline script - Use the provided DSL script (as opposed to take it from filesystem)
  5. Write short script creating one simple job based on example provided by trainer
  6. Execute seed job to make your job created
  • Q. Is it easy to write inline script? What bother you most?
  • Q. How the mentioned problems could be solved/mitigated?

Extra tasks

  1. Extend your job by adding extra steps and publishers

6.2. Jenkins Job DSL - leverage your IDE

Outline. Create simple CI job in your IDE using Job DSL.

6.2.0. Jenkins Job DSL - plugins installation

  1. Ensure the following plugins are installed
  • build-timeout
  • compact-columns
  • dashboard-view
  • delivery-pipeline-plugin
  • filesystem_scm
  • flexible-publish
  • git
  • gradle
  • groovy-postbuild
  • job-dsl
  • jobConfigHistory
  • nested-view
  • parameterized-trigger
  • rundeck
  • timestamper
  • view-job-filters
  • Hint. Boring with manual plugin installation? Use the following script in Jenkins -> Manager Jenkins -> Script Console
List<String> plugins = [
        'build-timeout',
        'compact-columns',
        'dashboard-view',
        'delivery-pipeline-plugin',
        'flexible-publish',
        'filesystem_scm',
        'git',
        'gradle',
        'groovy-postbuild',
        'job-dsl',
        'jobConfigHistory',
        'extra-columns',
        'nested-view',
        'parameterized-trigger',
        'rundeck',
        'timestamper',
        'view-job-filters',
]

PluginManager pluginManager = PluginManager.createDefault(Jenkins.instance)
pluginManager.install(plugins, true)
  • Hint. Plugins are installed in background. Follow Jenkins logs to determine time when Jenkins should be restarted.

6.2.1. Jenkins Job DSL - seed creation

  1. Clone job-dsl-workshop project.
  2. Create job-dsl-workshop-seed Freestyle project
  3. Configure your local project directory as job SCM
  • Switch Source Code Management to "File System"
  • Hint. Missing "File System" option to select? Ensure you have File System SCM installed
  • Provide path to your directory with job-dsl-workshop cloned
  • Enable filtering file by wildcards: **/.git/**, **/build/**
  1. Configure Gradle build
  • Add Invoke Gradle script step
  • Select Use Gradle Wrapper
  • Provide clean check as tasks to execute
  1. Configure Job DSL job definitions processing
  • Add Process Job DSLs step
  • Provide relative location of your job definitions (jobs/*.groovy) in Look on Filesystem
  • Set actions for removed elements to Delete
  • Click "Advanced" and provide additional classpath - build/classes/main and build/resources/main
    • Hint. Additional classpath is redundant right now, but will be useful having custom helper classes
  1. Save your changes
  2. Run newly created job
  • Q. Is the build executed successfully?
  • Q. Are there any new jobs generated?
    • No? Proceed to the next section

6.2.2. Jenkins Job DSL - writing seed job

  1. Import project job-dsl-workshop in your IDE
  • Idea (recommended) - File -> Open -> build.gradle
  • Eclipse - check README.md in project root directory
  1. Examine content of jobs directory
  2. In s1_1_simple_single.groovy (jobs directory) write code creating simple job executing shell script (or batch file) printing "Hello Job DSL!"
  • Hint. Leverage code completion in your IDE. Key elements to use: job, steps
  • Hint. Use JavaDoc (and/or source code) for Job DSL methods (Idea: CTRL-Q and CTRL-B)
  1. Rerun job-dsl-workshop-seed in Jenkins
  • Hint. Job generation failed during seed execution? Unignore in code JobScriptsSanitySpec to get faster feedback next time.
  1. Is there any new job created?
  • Hint. Examine seed job console output or Generated Items section (on seed job page)
  1. Execute created job verifying that requested text is printed in console output

6.2.3. Jenkins Job DSL - extending your job

  1. Using s1_2_extended_single.groovy write Job DSL code creating job (name it sample-gradle-build) building Gradle project
  2. Implement the first iteration which:
  1. Verify in Jenkins that proper jobs is generated and does all requested things
  • In addition to job execution it is good to manually check jobs configuration using UI (Configure page for given job)
  1. Iteration 2. Display timestamp next to every line in console output
  • Hint. Extra actions pre/post job execution can be found in wrapper closure
  1. Iteration 3. Add automatic build triggers:
  • nightly SCM polling (@midnight expression is ok)
  • weekly build regardless of changes in code (every Monday at 5 AM)
  • Hint. Examine element available in triggers closure
  1. Iteration 4. Add publisher generating nice report for JUnit test execution
  • not failing the build even if there are no tests in given project

6.2.4. Jenkins Job DSL - multiple jobs

  1. Generate jobs (the same as in previous step) for every project ending with -gradle-ci in solidsoft-training organization on GitHub - use s1_3_extended_multiple.groovy
  • Hint. Leverage Groovy generate URL of that projects
  • Q. For what else Groovy logic could used in that kind of scripts?

6.2.5. Jenkins Job DSL - view generation

  1. Generate view named seeds collecting all seeds in your Jenkins
  • Hint. Use List View (and corresponding listView() method instead job())
  • For flexibility, view should filter jobs using regular expression
    • Jobs ending with -seed seems to good candidate to include
  • View should display following information:
    • Status of the last build
    • Weather report
    • Job name
    • Last success time
    • Last failure time
    • Last execution duration
  • Q. What column by default are included in generated view?

6.2.6. Jenkins Job DSL - custom configuration (extra task - challenging)

  1. Generate enhanced view named fancy-seeds collection all seeds in your Jenkins
  • That view should behave the same as the previous one
  • View should display following information
    • Status of the last build
    • Weather report
    • Job name
    • Last statuses (aggregated success/unstable/failed column from Compact Columns plugin)
      • Hint. Having problem with find proper method in Job DSL? Skip it and add other columns
  • Last execution duration
  • Schedule a build button
  • Last/current console output link/butten
  1. Some plugins are not supported by Job DSL (such as Compact Columns) - manual XML node manipulation has to be used as workaround
  • Read The Configure Block section in project wiki
  • Check XML of manually created view with "Last statuses" column to get know what XML entries are needed to be inserted
    • Hint. Views are stored in config.xml
  1. Ensure columns are placed in aforementioned order.
  • Q. How columns and configure block can be ordered?
  • Q. What to do to make given plugin supported out-of-box by Job DSL?
  1. Brood about difference between inline and "civilized' Job DSL development
  • Q. Is code completion useful to fulfill your task?
  • Q. What other benefits of using separate Gradle project to handle Job DSL configuration do you see?
  • Q. How do you test your changes? Do you see a field for improvements?
  • Q. How to handle a seed job creation itself in production Jenkins?
  • Q. Remember setting action for removed jobs/views to DELETE? Is it safe? What could be consequences of using both DELETE and IGNORE?

Extra tasks

  • Play with some (interesting for your) feature provided by Groovy+Postbuild+Plugin
  • Start with manual edition in selected job
  • When satisfied enable them with Job DSL

6.3. Jenkins Job DSL - deployment pipeline

Follow the instructions provided by the trainer.

Exercise 7. Jenkins as code - Jenkins Pipeline Plugin edition

Exercise 7.1. Declarative pipeline - basics

  1. Install the following plugins:
  • Pipeline Utility Steps (id pipeline-utility-steps) - provides some extra steps which potentially may be useful
  • Job Configuration History (id jobConfigHistory) - helps review changes done between builds
  • AnsiColor (id ansicolor) - Ansi codes rendering (colorized output) Hint. You can install it using Configuation as Code or a Groovy script
  1. Write a simple one-stage pipeline (Jenkins -> New Item -> <enter name> -> Pipeline -> OK) which outputs a message on an execution (copy-paste the following code):
pipeline {
   agent any
   stages {
      stage('Hello stage') {
         steps {
            echo 'Hello from Declarative pipeline!'   
         }
      }
   }
}

2b. Get familiar with the Pipeline syntax link (aka Snippet Generator) available in every Pipeline job on the left

  • Check out also Declarative Directive Generator available from the Pipeline syntaxt view
  1. Add a shell step execution displaying the installed Java version.
  • Hint. Use the Snippet Generator to get a name of the required step
  1. Create an another stage Var stage with a single step
  2. Define (globally for the pipeline) a variable named MESSAGE and display it using an echo step and ${VAR} syntax
  • Hint. Use Declarative Directive Generator to find the proper directive
  • Q. Do you remember what is the main difference between single quotas ' and double quotas " in Groovy? Check it in practice.

Extra tasks (for people with docker installed locally)

  • Duplicate your stage and specify the agent with different Java image for each of them (e.g. openjdk:8u191-jdk-alpine and adoptopenjdk/openjdk11:jdk-11.0.1.13-alpine-slim)
  • Check the output to verify that a proper Java version is used
  • Hint. Use Declarative Directive Generator to find the proper directive

Exercise 7.2. Parameters, credentials and pipeline options

  1. Create a String input parameter deployEnv and some description
  2. Create a boolean parameter forceDeployForTheSameVersion with a default value set to false
  3. Display them in the output of the another stage (remember to use ${params. } construction
  4. Run the pipeline a few times with different parameters
  • Q. Is it possible to filter displayed build by a parameter value?
  • Q. For which type of jobs parameterized jobs are useful?
  • Q. Explore other types of parameters. Which else do you see useful and where?
  1. Define a new username with password global credentials (or reuse existing one if any)
  2. Use the MY_CRED = credentials(CRED_ID) construction to fetch the credentials and assign it to a variable
  3. Leverage the fact that 2 extra variables with _USR and _PSW prefixes are created. Display them.
  • Q. What happens to displayed credentials?
  • Q. How can we test if a good value is used?
  1. Enable globally for your pipeline:
  • displaying timestamps
  • colorized output support
  • global timeout
  • Hint. Take a look at the options directive available in the Declarative Directive Generator
  • Hint. Beware minor issues in snippet/directive generators. timestamp() has to be a method call
  • Hint. Output coloring can be tested with the following step sh 'echo -e "\033[0;31m"Foo"\033[0m" Bar'

Extra tasks

  • Use currentBuild.displayName = construction to append parameter values to the build name. Which step has it be to surrounded by to make it work?

Exercise 7.3. Interactive input and post actions

  1. Add an another stage named Deploy.
  2. Make it a step requiring a manual acceptation (OK/Cancel).
  • Hint. Declarative Directive Generator is your friend to find a proper directive
  1. Run the pipeline a few times accepting or not a deployment

  2. Extend the input step to an extra String parameter ENVIRONMENT with a default value PROD1 which can be used to (fake) override default deploy environment.

  3. Define actions for selected post build (or post stage) condition (e.g. displaying a text simulating a sent notification).

  • Hint. Again, use Declarative Directive Generator to find an appropriate directive
  • Q. In what cases, do you see it useful?

Extra tasks

  • Try to use more advanced features of an input to provide a way to provide a value using a remote HTTP call (e.g. with curl).

Exercise 7.4. Building Java project

Outline. Use learned techniques to create a pipeline to build the forked JUnit 4 from the Exercise 1.

  1. Create a new pipeline
  2. Create at least 2 stages
  3. Fetch JUnit 4 code from your GitHub repository
  4. Run Maven directly or using a wrapper
  5. Collect test execution report
  6. Add extra features such as colorized output or execution timestamps
  • Hint. Remember about Snippet Generator and Declarative Directive Generator
  • Hint. You can reuse parts of code from the previous pipeline

Exercise 7.5. Using declarative pipeline from Jenkinsfile in Git repository

  1. Clone your forked version of junit 4 locally
  2. Copy-paste the Declarative Pipeline from the previous exercise to Jenkinsfile created in the cloned project root directory
  • Hint. That pipeline should be working. Having issues with your own pipeline from the previous exercise ask colleagues or the trainer 3. Commit Jenkinsfile (to already existing branch or a new one) and push it to GitHub
  1. Create another pipeline job in Jenkins (New Item -> Pipeline) with name suggesting that Jenkinsfile will be used
  2. Instead of Pipeline script in the pipeline configuration choose Pipeline script from SCM
  3. Point to your forked JUnit 4 repo on GitHub
  • Hint. Remember about a branch name if it is not in master
  1. Run your pipeline
  • Q. What happened during that operation?

Exercise 7.6. Scripted pipeline

Outline. Create build pipeline for JUnit using Pipeline script (scripted pipeline).

  1. Create a new pipeline job junit-pipeline: New Item -> Pipeline
  2. Configure the Pipeline script to:
  • Clone JUnit from your the GitHub repository
  • Build it using Maven (or Maven Wrapper)
  • Publish the JUnit tests execution report
  • Hint. Take the advantage of one of the available examples in the "try sample Pipeline..." dropdown - adjust it to your needs
  • Hint. -Dmaven.test.failure.ignore=true can be useful again
  • Hint. Some other actions required? Click the Pipeline Syntax link to generate code snipped for selected plugin or Steps reference (3 positions lower) to get know more possible options (such as timeout or coloring).

Exercise 8. Administrative operations with Groovy script

Follow the instruction provided by the trainer.

Exercise 9. Ad-hock slaves in Jenkins (bonus task)

Outline. Launch and connect to your local Jenkins instance an extra agent

  1. Install the Swarm plugin (ID: swarm).
  2. Download the latest version of the swarm-client (or use the unofficial jenkins-swarm-slave image from Docker Hub)
  3. Enable JNLP in Jenkins (Jenkins -> Configure Jenkins -> Configure Global Security -> Agents -> TCP port for JNLP agents -> Fixed port)
  4. Launch swarm-client.jar (directly - java -jar swarm-client.jar or using a docker image) with -help to see possible parameters
  5. Launch swarm-client.jar with the parameter pointing your master server location
  6. On success (INFO: Connected) check in Jenkins UI the availability of a new slave
  7. Try to execute some job/pipeline on it
  • Hint. Putting your master node "offline" may be useful

Extra tasks

  • (With permission) try to connect to some other Jenkins master in the network (firewall on that computer has to pass the fixed port configured for JNLP)
  • Try to use auto-discovery mode
  • Limit number of executors to 1 (modifying swarm-client.jar execution parameters)

Exercise 10. Deployment with GitLab CI (bonus task)

Outline. Deploy static webpage to GitLab pages.

  1. Login to GitLab (NOT GitHub) account or create one
  2. Fork one of example (page) projects
  • Hint. All should work, but only "jekyll" is supported by the trainer if in trouble :)
  1. Enable shared runners for forked projects
  • Settings (gear button) -> CI/CD Pipelines -> Shared Runners -> Enable shared Runners
  1. Proper .gitlab-ci.yml was available in forked project - there is no need to modify it.
  2. Edit your site (using GitLab UI)
  • In case of "jekyll" project _config.yml
  1. Follow GitLab CI runner execution (running blue button on the left of commit information)
  2. Visit your new webpage: https://YOUR_USERNAME.gitlab.io/PROJECT_NAME
  • Your modifications should be visible

Extra tasks

  1. Take a look at .gitlab-ci.yml content - try to identify essential elements
  1. Make your website available as your default user website - https://YOUR_USERNAME.gitlab.io
  • It can be achieved by renaming project name (in "Rename repository" section! - not at the top of page) to YOUR_USERNAME.gitlab.io and re-triggering build
    • Hint. Build can be triggered by extra commit or with API - consult Settings -> CI/CD Pipelines to generate token and get sample requests
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment