Skip to content

Latest commit

 

History

History
122 lines (78 loc) · 6.78 KB

workshop2.adoc

File metadata and controls

122 lines (78 loc) · 6.78 KB
Raw

Jenkins Pipeline Workshop

Workshop #2 - Pipeline As Code

GitHub Credentials

Go back to your Jenkins, let’s now add your GitHub credentials.

This token needs to have all permissions on repo, admin:org, admin:repo_hook, admin:org_hook and user:email.

You will then use that token as a password alternative.

Caution
 Attention, GitHub will not let you see the token again afterwards, save it correctly somewhere.

Add credentials with your Github login, using the token previously generated as the password.

Note
 For your information, you are the only one allowed to access your Jenkins instance, and the API token is encrypted on the disk. However, it is obviously strongly recommended that you revoke that token at the end of the workshop.

Create a GitHub organization

Jenkinsification of the project

Let’s now add a Jenkinsfile to your project.

  • On your machine, clone the previously forked repo: [email protected]:${YOUR_ORGANIZATION}/spring-petclinic.git

  • Create a Jenkinsification branch from the master one, and create a Jenkinsfile file at the root of your repo:

$> git checkout -b Jenkinsification && touch Jenkinsfile

  • Transform the Scripted Pipeline created during the first part of the workshop, into a Declarative Pipeline (must begin with pipeline{ …​ })

Note
 To make your life easier, you can try to scaffold your Pipeline using the Blue Ocean Visual Editor. Follow instructions on http://${IP_JENKINS}:8080/blue/organizations/jenkins/create-pipeline This project is still in early stages, though it’s improving very quickly, so you could see some discrepancies [1].
Tip
 You should find the following helpful: https://jenkins.io/doc/book/pipeline/

Syntax validation

Using documentation du CLI Jenkins to verify the syntax of your Jenkinsfile remotely.

To be able to connect to the Jenkins CLI, you will need to generate an SSH keypair, and add the public key in your user account in the typical way. Cf. https://jenkins.io/doc/book/managing/cli/#authentication

Note
 If you don’t know what to do with the previous, please ask us! :-)

You should be able to run the following command (GitBash on Windows) :

$> java -jar cli.jar -i your_SSH_key -s http://${IP_JENKINS}:8080 declarative-linter --username ${YOUR_JENKINS_USER} --password ${YOUR_PASSWORD} < path/to/your/Jenkinsfile

Same command on Windows:

cat .\Jenkinsfile | java -jar jenkins-cli.jar -i your_SSH_key -s http://${IP_JENKINS}:8080 declarative-linter
Tip
 the CLI lets you do a big amount of things remotely. Use the help command to output the exhaustive list of possible actions (or use http://${IP_JENKINS}:8080/cli).

Create a GitHub Organization job

  1. Once you’ve validated your Jenkinsfile, commit and push those modifications to your fork.

  2. On Jenkins, create a new GitHub Organization job and complete the configuration to point to your organization. Select the credentials you created previously. Using the default options for the rest should be enough.

Jenkins should now scan all the branches of all the repositories of your organization, looking for Jenkinsfiles. Then it will create and execute the associated jobs.

Note
 When you have successfully ran a build, you may notice a sentence at the end of the build GitHub has been notified of this commit’s build result. On GitHub’s side, for each of your commit that is successful or failing, the build status will be shown next to it.
Tip
 When in "development mode" for Jenkins Pipeline, it is generally recommended to now use the Replay feature to avoid having to commit & push to test changes.

Building binaries

Let’s now fill in the last "holes" in our Pipeline so that it becomes at least a bit useful :-).

  1. In the build & unit tests stage, configure your pipeline to run a Maven build. There are many ways to achieve this, as always, we recommend using the withMaven step (see doc)

  2. In the build & unit tests stage, after the Maven build, add a step to stash the generated binaries target/\*.jar.

  3. In the staging and deploy stages, add an unstash step for the binaries. Make sure the binary is available in the workspace using ls -l target after the unstash call.

  4. As Jenkins reuses workspaces by default when possible, it’s recommended to always cleanup workspaces when using steps like unstash to make sure the workspace is clean each time and avoid issues. So add that cleanup just before calling unstash.

Note
 Use the Pipeline documentation and the Snippet Generator.

Static code analysis

  1. Open your SonarQube instance: the default credentials are admin/admin. Change directly the admin password.

  2. Generate a SonarQube API token in the Security part in the options of the admin user: see http://${IP_SONARQUBE}:9000/account/security/

  3. In the global configuration of Jenkins, configure the informations to access your SonarQube instance.

  4. Improve the static-analysis stage to allow a SonarQube analysis (see withSonarQubeEnv step ⇒ documentation)

Re-run your Pipeline, you should now see the SonarQube icon next to your build. Open SonarQube and check the analysis went fine.

Restrict deploys to master branch only

As we generally work with many branches with Git, it can be complex to manage many deployments of different versions of our applications to different deployment environments. To keep things simple, we’re going to restrict deploys to the master branch only.

  1. Using the Pipeline documenration, adjust things so that the staging, manual-approval and deploy stages trigger only when the current branch is master.

  2. Push your modifications to the Jenkinsification branch and observe how it goes. The staging, manual-approval and deploy stages should now be shown as skipped

  3. Merge the Jenkinsification branch on master now, push your modifications and have a look at the build. The deployment steps should now be enabled.

1. contributions are warmly welcome! :-)