Difference between revisions of "Pull Requests"
(→File System Configuration) |
|||
(54 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
+ | = Introduction = |
||
− | * [[ GitHub Pull Requests | GitHub Pull Requests ]] |
||
+ | For GitHub, GitLab and Bitbucket, commits, Pull Requests / Merge Requests code changes can be analyzed using the Globalyzer Scanner. |
||
− | * [[ Distributed Jenkins | Distributed Jenkins ]] |
||
− | The Lingoport Suite offers two options for Pull Requests from your repository. The Pull Request can be done on your Lingoport Server or there is a distributed option that uses the Master/Agent capability of Jenkins to distribute the work among several nodes. |
||
+ | A Webhook lets a Jenkins job know to scan the code committed. Only the code modified is analyzed by the Globalyzer scanner. The result is a comment in GitHub, GitLab or Bitbucket showing issues detected. |
||
− | To use the Distributed Pull Request option, please install the [[Lingoport_Suite_Installation#NodeInstaller|Node Installer]] optional software. |
||
+ | In the example below, one line was modified and the Globalyzer scan shows an i18n issue. The developer can decide how to handle it. |
||
− | = GitHub and Git Pull Requests= |
||
− | GitHub is a Web-based Git repository hosting service. It offers all of the distributed revision control and source code management (SCM) functionality of Git as well as adding its own features. |
||
+ | [[File:PullRequestExample.png|600px|center]] |
||
− | Files can be committed in a Git branch or directly in the Master branch. When committing files in a branch, pull requests let you know what changes you've made to a repository before they are committed to the repository's master branch. Once a pull request is sent, interested parties can review the set of changes, discuss potential modifications, and even push follow-up commits if necessary. |
||
+ | This is unobtrusive and provides actionable i18n information to developers. |
||
− | [[File:PullRequest.png|800px]] |
||
− | = Configuring Pull Requests = |
||
− | == Verify the Lingoport Dashboard Plugin == |
||
− | The Pull Requests rely on the Dashboard GitHub plugin. If your system was installed using the Stack Installer, this plugin should have been included. Verify that it is installed. |
||
− | <ol> |
||
− | <li> Go to the Lingoport Dashboard and log in as Administrator. |
||
− | <li> Select the '''Administration''' tab at the top of the window. |
||
− | <li> Select the '''System''' pulldown and '''Update Center''' |
||
− | <li> With '''Installed''' selected, search for '''GitHub'''. You should find a plugin with the description: "Provide some integration between GitHub and SonarQube" |
||
− | </ol> |
||
− | If you do not find the plugin installed, select '''Available''', search for 'GitHub' again and '''Install''' it. |
||
+ | = Video Introduction to GitHub, GitLab, and Bitbucket = |
||
− | == Set up Nodes on Jenkins == |
||
+ | Below are short introductions of the functionality around Globalyzer scanning for Git repository: |
||
+ | |||
+ | * '''GitHub''' https://vimeo.com/817611647 |
||
+ | * '''GitLab''' https://vimeo.com/817610534 |
||
− | If you are using the Distributed Pull Requests option, the first thing that needs to be done is to set up nodes in Jenkins. If you installed the [[Installing_the_Node_Installer|Node Installer]] and followed its setup instructions, there should be a master system (where Jenkins and Lingoport Dashboard are hosted) and at least one agent or node system. The master system should be able to ssh into the agents' centos user and the jenkins user. If this is not completed, make sure that is done before proceeding further. |
||
+ | * '''Bitbucket''' https://vimeo.com/826230267 |
||
− | If you are not using nodes and agents, skip to the PullRequests section. |
||
− | = |
+ | = Pull Requests via Jenkins Running on Docker = |
− | On the Master system, in Jenkins, select <b>Manage Jenkins → Manage Nodes → New Node</b> |
||
+ | == Prerequisites == |
||
− | Set up each agent node using this example: |
||
+ | <ol> |
||
+ | <li> VM running Linux and Docker |
||
+ | <li> JQ JSON Parser - Statically compiled binary version |
||
+ | <ol> |
||
+ | <li> https://stedolan.github.io/jq/ |
||
+ | </ol> |
||
+ | <li> GitHub PAT credentials to connect to GitHub |
||
+ | <ol> |
||
+ | <li> The user for these PAT credentials has read access to the repository |
||
+ | </ol> |
||
+ | <li> Globalyzer.com credentials for logging in to globalyzer.com |
||
+ | <ol> |
||
+ | <li> username |
||
+ | <li> password |
||
+ | </ol> |
||
+ | <li> Obtain a copy of Globalyzer Lite from https://www.globalyzer.com/gzserver/home/installclient (requires Globalyzer.com credentials) |
||
+ | <li> A copy of your Globalyzer.license from globalyzer.com or your local globalyzer server instance. |
||
+ | <li> Jenkins will use the following URL to download all plugins required during the installation. This URL is required to be reachable from the VM Jenkins is being installed on prior to starting the install. |
||
+ | <ol> |
||
+ | <li> https://updates.jenkins.io/update-center.json |
||
+ | </li> |
||
+ | </ol> |
||
+ | <li> Optional: |
||
+ | <ol> |
||
+ | <li> Apache or nginx could be installed and running on the VM itself as a reverse proxy to front the Jenkins instance </li> |
||
+ | </ol> |
||
+ | </ol> |
||
+ | == File System Configuration == |
||
− | [[File:nodes_config.png|800px]] |
||
+ | <p> |
||
+ | If Apache is installed as per normal for many Lingoport systems, the following is required to configure Apache to permit proper connection to the Jenkins Docker container |
||
+ | </p> |
||
+ | <ol> |
||
+ | <li> Create the directory structure for the volume storage used by jenkins. Be sure there is sufficient space. Base install will consume 650MB of space for the volume itself. </li> |
||
+ | <code> mkdir ~/docker/jenkins/lingoport/bin </code> |
||
+ | <li> Place the Globalyzer License into the lingoport directory created </li> |
||
+ | <code> cp ~/PRC-Docker/Globalyzer.license ~/docker/jenkins/lingoport/ </code> |
||
+ | <li> Copy the downloaded copy of Globalyzer Lite into the lingoport directory </li> |
||
+ | <code> cp ~/PRC-Docker/globalyzer-lite-VERSION.zip ~/docker/jenkins/lingoport/ </code> |
||
+ | <li> Copy the jq binary into the bin directory and set the permissions </li> |
||
+ | <code> |
||
+ | cp -p ~/PRC-Docker/jq ~/docker/jenkins/lingoport/bin/ |
||
+ | chmod +x ~/docker/jenkins/lingoport/bin/jq |
||
+ | </code> |
||
+ | <li> Unzip the Globalyzer Lite zip file in the lingoport directory and remove the zip file once complete </li> |
||
+ | <code> |
||
+ | cd ~/docker/jenkins/lingoport |
||
+ | unzip globalyzer-lite-VERSION.zip |
||
+ | rm ./globalyzer-lite-VERSION.zip |
||
+ | </code> |
||
+ | <li> Create the .globalyzerrc file in the jenkins home directory, add the proper credentials and set the permissions </li> |
||
+ | <code> |
||
+ | vi .globalyzerrc |
||
+ | chmod 600 .globalyzerrc |
||
+ | </code> |
||
+ | <li> Confirm the contents of the .globalyzerrc file are entered like this: (Note no equals or colon, just whitespace between key and value) </li> |
||
+ | <code> |
||
+ | username <GLOBALYZER LOGIN USERNAME> |
||
+ | password <GLOBALYZER LOGIN PASSWORD> |
||
+ | server <URL of Globalyzer Server> |
||
+ | </code> |
||
+ | </ol> |
||
+ | == Launching the Jenkins Docker Container == |
||
− | Select '''Add''' to create the jenkins ssh credentials |
||
+ | <p> Retrieve these two items as they are now required to proceed </p> |
||
− | [[File:Credentials.png|600px]] |
||
+ | <ol> |
||
+ | <li> Obtain the UID and GID for the user that Docker is being ran by. |
||
+ | <li> Identify the the port that Jenkins should be listening on. |
||
+ | <ol> |
||
+ | <li> In the example below it was determined to be 8085 </li> |
||
+ | </ol> |
||
+ | </li> |
||
+ | </ol> |
||
+ | <p> The next command line is an example of what would be used to start the docker instance for Jenkins. Here is an explanation of the switches being used when no proxy is required for the container to reach required destinations. </p> |
||
+ | <p> |
||
+ | The command string will create a new container instance that will automatically restart the container unless specifically |
||
+ | stopped. It will also reuse the existing container on a restart of the OS. If the container is stopped before the |
||
+ | reboot is performed using <i> sudo docker stop "CONTAINTER ID" </i>, it will need to be started using <i>sudo docker start "CONTAINER ID"</i> |
||
+ | </p> |
||
+ | <ol> |
||
+ | <li> The -d detaches the command being run from the terminal. Normally this is something that will only be used |
||
+ | once everything is in place and confirmed to be working. For initial startup, its use can be ignored. </li> |
||
+ | <li> The -u is for setting the uid/gid of the user that owns the volume storage identified earlier. This user |
||
+ | should also be the user that is starting the docker instance. </li> |
||
+ | <li> The -p 8085:8080 is the port external to internal mapping identified earlier. The 8080 would never change, |
||
+ | only the external port is modifiable </li> |
||
+ | <li> The -p 50000:50000 is for mapping between Jenkins instances only. Not required for standalone systems. </li> |
||
+ | <li> The JENKINS_OPTS sets the baseurl for the application </li> |
||
+ | <li> The -v mounts the prior locally created file system to the running docker instance as a volume and mas it. </li> |
||
+ | <li> The jenkins/jenkins:lts-jdk17 is the long term support image for Jenkins. Currently, it is Jenkins 2.452.2 </li> |
||
+ | </ol> |
||
+ | |||
+ | <code> |
||
+ | sudo docker run -d -u 1000:1000 -p 8085:8080 -p 50000:50000 \ |
||
+ | --env JENKINS_OPTS="--prefix=/jenkins" --restart=unless-stopped \ |
||
+ | -v /USER_HOME_DIR/docker/jenkins:/var/jenkins_home jenkins/jenkins:lts-jdk17 |
||
+ | </code> |
||
+ | <p> |
||
− | Nothing needs to be done with the master node. Online the new nodes and the console output should look like: |
||
+ | If a proxy is required to be leveraged by the container to reach destinations the next command line would be used to start the docker instance for Jenkins instead of the previous one. Note the additional env variables that are added to support the proxy. |
||
+ | </p> |
||
− | < |
+ | <code> |
+ | sudo docker run -d -u 1000:1000 -p 8085:8080 -p 50000:50000 \ |
||
− | [01/26/18 16:26:19] [SSH] Opening SSH connection to ec2-54-227-210-213.compute-1.amazonaws.com:22. |
||
+ | --env JENKINS_OPTS="--prefix=/jenkins" \ |
||
− | [01/26/18 16:26:19] [SSH] SSH host key matches key in Known Hosts file. Connection will be allowed. |
||
+ | --env http_proxy="http://<PROXY_URL>:<PORT>" \ |
||
− | [01/26/18 16:26:19] [SSH] Authentication successful. |
||
+ | --env https_proxy="http://<PROXY_URL>:<PORT>" \ |
||
− | [01/26/18 16:26:19] [SSH] The remote user's environment is: |
||
+ | --restart=unless-stopped \ |
||
− | BASH=/usr/bin/bash |
||
+ | -v /home/centos/docker/jenkins:/var/jenkins_home jenkins/jenkins:lts-jdk17 |
||
− | BASHOPTS=cmdhist:extquote:force_fignore:hostcomplete:interactive_comments:progcomp:promptvars:sourcepath |
||
+ | </code> |
||
− | .... |
||
− | </pre> |
||
+ | <p> |
||
− | ===Verify the Agent setup in Jenkins === |
||
+ | This will download the required images and start the container. There will be a message about initial password, |
||
− | To verify that the Agent setup is correct, use the Jenkins 'Debug' job. |
||
+ | make note of it as it will be used to log into Jenkins |
||
+ | </p> |
||
− | Under '''General''' check '''Restrict where this project can be run''' and set it to '''lingoport'''. |
||
+ | |||
− | In the '''Execute Shell''' leave only: |
||
− | < |
+ | <code> |
+ | ************************************************************* |
||
− | whoami |
||
+ | ************************************************************* |
||
− | pwd |
||
+ | ************************************************************* |
||
− | sleep 5 |
||
+ | Jenkins initial setup is required. An admin user has been created and a password generated. |
||
− | </pre> |
||
+ | Please use the following password to proceed to installation: |
||
+ | |||
+ | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
||
+ | |||
+ | This may also be found at: /var/jenkins_home/secrets/initialAdminPassword |
||
+ | |||
+ | ************************************************************* |
||
+ | ************************************************************* |
||
+ | ************************************************************* |
||
+ | </code> |
||
+ | == Browser Connected Configuration == |
||
− | Run the job. The console output should show: |
||
+ | <p> Go to application using the browser and use the above password to log in initially </p> |
||
− | <pre> |
||
+ | [[File:Unlock-jenkins.png|noframe|500px]] |
||
− | Started by user anonymous |
||
− | Building remotely on Agent1 (lingoport) in workspace /var/lib/jenkins/jenkins_slave/workspace/Debug |
||
− | [Debug] $ /bin/sh -xe /tmp/jenkins7953464360000549139.sh |
||
− | + whoami |
||
− | jenkins |
||
− | + pwd |
||
− | /var/lib/jenkins/jenkins_slave/workspace/Debug |
||
− | + sleep 5 |
||
− | </pre> |
||
+ | <p> At this screen select Install Suggested Plugins </p> |
||
− | Note that it shows that it ran on the Agent using the lingoport label. |
||
+ | [[File:Customize-jenkins.png|noframe|500px]] |
||
+ | <p> The plugins will begin to install, this will only be a few minutes. </p> |
||
− | == Jenkins PullRequest and DistributedPullRequest jobs== |
||
+ | [[File:Getting-started-jenkins.png|noframe|500px]] |
||
− | There are two Jenkins job templates for Distributed Pull Requests. |
||
− | * Lingoport.SampleLite-PullRequest |
||
− | * Lingoport.SampleLite-DistributedPullRequest |
||
+ | <p> Create the Admin account. This will be a new account outside of what was used to connect initially. It will be the administrator account. </p> |
||
− | The Distributed Pull Request makes use of the Jenkins master/agent system. |
||
+ | [[File:Create-first-admin-user-jenkins.png|noframe|500px]] |
||
+ | <p> This sets up the URL with a path to the instance. It will include /jenkins so it should be something like “http(s)://<YOUR FQDN/jenkins/ </p> |
||
− | Create a new Jenkins job using the '''Lingoport.SampleLite-PullRequest''' or '''Lingoport.SampleLite-DistributedPullRequest''' template. This should be modeled on an existing Jenkins project. |
||
+ | [[File:Instance-config-jenkins.png|noframe|500px]] |
||
+ | <p> The base Jenkins system install is complete at this point. </p> |
||
− | For example, if you have a Jenkins project called '''Acme.BigProject''' and you want to use PullRequests with this project and repository, name the new project '''Acme.BigProject-PullRequest'''. |
||
+ | [[File:Jenkins-ready.png|noframe|500px]] |
||
+ | <p> Click Start using Jenkins and the Dashboard appears </p> |
||
− | === Configuring the PullRequest Jenkins job === |
||
+ | [[File:Dashboard-jenkins.png|noframe|500px]] |
||
− | Once you have created the new PullRequest project, some configurations need to be modified. |
||
− | <ol> |
||
− | <li> Make sure the name is '''<Group>.<Project>-PullRequest'''. The <Group>.<Project> Jenkins job should already exist and have been executed. Anything other than <Group>.<Project>-PullRequest may cause problems. |
||
− | <li> Leave the '''payload''' parameter alone. Do not modify it. |
||
− | <li> If nodes have been set up for other projects, select '''Restrict where this project can be run''' and set it to '''master'''. If nodes have NOT been set up, nothing needs to be done with this option. |
||
− | <li> Under '''Build Triggers''', select '''Trigger builds remotely (e.g., from scripts)''' and set the value to '''HOOK'''. |
||
− | <li> Under Build, and Execute Shell, set the Project Definition File for <Group>.<Project> |
||
− | <pre> |
||
− | LITE_PROJECT_DEFINITION=/var/lib/jenkins/jobs/<Group>.<Project>/workspace/lingoport/LiteProjectDefinition.xml |
||
− | </pre> |
||
− | <li> '''Save''' the configuration and '''Enable''' the project. |
||
− | </ol> |
||
− | From the command line console, in /var/lib/jenkins/Lingoport_Data/Dashboard/Projects/GROUPNAME.PROJECTNAME-PullRequest/ (this may need to be created), make a '''sonar-project-pr.properties''' file that looks like: |
||
− | <div style="margin-left: 2em;"> |
||
− | <pre> |
||
− | # Make sure a Dashboard user is set up with the credential below |
||
− | # otherwise the dashboard will not accept the pushed data |
||
− | # |
||
− | sonar.login=admin |
||
− | sonar.password=<admin password> |
||
− | # |
||
− | # Do not change the properties below |
||
− | # the capital letter tokens will be replaced by |
||
− | # build scripts |
||
− | # |
||
− | sonar.projectKey=PullRequest:scan |
||
− | sonar.projectName=PullRequest |
||
− | sonar.projectVersion=PR |
||
+ | <p> The alert is caused by this running locally and not using nodes. Click on it and select “Dismiss” </p> |
||
− | sonar.language=lport |
||
+ | [[File:Node-details-jenkins.png|noframe|500px]] |
||
− | sonar.encoding=UTF-8 |
||
+ | <p> If once this is cleared, this message appears. It is due to a reverse proxy being used that needs to have some additional configuration. </p> |
||
− | sonar.sources=/var/lib/jenkins/jobs/<Group>.<Project>-PullRequest/workspace |
||
+ | [[File:Proxy-error-jenkins.png|noframe|500px]] |
||
− | sonar.lingoport.project.root=/var/lib/jenkins/Lingoport_Data/Dashboard/Projects/<Group>.<Project>-PullRequest |
||
+ | <p> When using Apache as a reverse proxy, adding these two entries to the virtual host SSL configuration should correct the error. </p> |
||
− | # |
||
− | # For the GitHub SonarQube Plugin to push the results to GitHub PR |
||
− | # The same for all: |
||
− | sonar.analysis.mode=preview |
||
− | sonar.github.endpoint=https://api.github.com |
||
− | sonar.github.disableInlineComments=true |
||
+ | <code> |
||
− | # Specific for this install |
||
+ | RequestHeader set X-Forwarded-Proto "https" |
||
+ | |||
+ | RequestHeader set X-Forwarded-Port "443" |
||
+ | </code> |
||
+ | == Add GUI Configuration Items for Pull Requests and Commits == |
||
+ | <p> Install and additional plugin called “Discard Old Builds” by going to Manage Jenkins → Manage Plugins → Available Plugins and search for “Discard old builds” </p> |
||
− | # Specific to this GitHub Project |
||
+ | [[File:Plugins1-jenkins.png|noframe|500px]] |
||
− | sonar.github.login=<myGitLogin> |
||
+ | |||
− | sonar.github.oauth=<created token> |
||
+ | <p> Install an additional plugin called “Throttle Concurrent Builds” by going to Manage Jenkins → Manage Plugins → Available Plugins and search for “Throttle Concurrent Builds”</p> |
||
− | sonar.github.repository=<Repo> #for example: NASA/nasa-latex-blocks |
||
+ | [[File:Plugins2-jenkins.png|noframe|500px]] |
||
− | </pre> |
||
+ | |||
− | </div> |
||
+ | <p> Once plugin is installed to go Manage Jenkins → Configure System → Throttle Concurrent Builds and select Add Category: </p> |
||
− | '''Note''': |
||
+ | |||
− | <code>sonar.github.pullRequest=<pr number></code> will be added at run time based on the Pull Request number to be analyzed. |
||
+ | <p> Create Category Name PRC_THROTTLE and set Maximum Total Concurrent Builds = 1 and Maximum Concurrent Builds Per Node = 1. </p> |
||
+ | |||
+ | <p> Select “Apply” to save </p> |
||
+ | |||
+ | <p> Set up the environment variables in Jenkins: </p> |
||
− | === Configuring the DistributedPullRequest Jenkins job === |
||
− | Once you have created the new DistributedPullRequest project, some configurations need to be modified. The DistributedPullRequest should be based on a <Group>.<Project> Jenkins job that has been executed. |
||
<ol> |
<ol> |
||
− | <li> |
+ | <li> Select the Environment Variables checkbox |
+ | <li> Select Add and add the following |
||
− | <li> Set the '''GIT_REPO''' parameter. This should be set to the form '''Company/Project''' as seen on GitHub. For example, in GitHub, NASA has many projects so the GIT_REPO would be set to NASA/nasa-latex-blocks |
||
+ | <ol> |
||
− | <li> Set the '''LITE_PROJECT_DEFINITION''' parameter to the value on the Agent. <code>$JENKINS_HOME/jenkins_slave/workspace/<Group>.<Project>-DistributedPullRequest/lingoport/LiteProjectDefinition.xml </code> |
||
+ | <li> For a GitHub Installation |
||
− | <li> Select '''Restrict where this project can be run''' and set it to '''lingoport'''. |
||
+ | <ol> |
||
− | <li> Under '''Build Triggers''', select '''Trigger builds remotely (e.g., from scripts)''' and set the value to '''HOOK'''. |
||
+ | <li> GITHUB_PRC_FILES = $JENKINS_HOME/lingoport/<globalyzer-lite-dir>/GitHub_PRC </li> |
||
− | <li> '''Save''' the configuration and '''Enable''' the project. |
||
+ | </ol> |
||
+ | <li> PATH = $PATH:$JENKINS_HOME/lingoport/bin |
||
+ | <li> If https is to be used for connecting to the git repos set to true. If ssh is to be used to connect to git repos set to false. |
||
+ | <ol> |
||
+ | <li> useHTTPS = true or false </li> |
||
+ | </ol> |
||
+ | </li> |
||
+ | <li> Optional - If Proxy is required: |
||
+ | <ol> |
||
+ | <li> Add entry _JAVA_OPTIONS with proxy details as shown in screenshot below </li> |
||
+ | <li> Dhttp.proxyHost=<FQDN> Dhttp.proxyPort=<PORT> Dhttps.proxyHost=<FQDN> Dhttps.proxyPort=<PORT> </li> |
||
+ | </ol> |
||
+ | </li> |
||
+ | </ol> |
||
+ | </li> |
||
</ol> |
</ol> |
||
+ | <br> |
||
+ | <p></p> |
||
+ | [[File:Env-var1-jenkins.png|noframe|500px]] |
||
+ | <br> |
||
+ | [[File:Env-var2-jenkins.png|noframe|500px]] |
||
+ | <br> |
||
+ | [[File:Jenkins_proxy_for_java.png|noframe|500px]] |
||
+ | <br> |
||
+ | <p> Click Apply and Save </p> |
||
+ | <br> |
||
+ | <p> Add new API token to be used by GitHub Webhook </p> |
||
+ | <p> In Jenkins create a new API token for the user that will be running the build. This will be required to be added to the webhook to permit connection back to the Jenkins instance </p> |
||
+ | The credentials used for GitHub will require read access to the git repository. |
||
+ | <ol> |
||
+ | <li> Select Dashboard → Manage Jenkins → Manage Users → Select the gear icon on the right side of the Admin user (Admin user created earlier) |
||
+ | <li> In the API Token section, select Add new Token |
||
+ | <li> Set the name of the new token to GitHub-PRC-TOKEN or something that is memorable and can identify with the PRC action. |
||
+ | <ol> |
||
+ | <li> Be sure to copy the token value as it will never be displayed beyond this time. </li> |
||
+ | </ol> |
||
+ | </li> |
||
+ | </ol> |
||
+ | <p></p> |
||
+ | [[File:Api-token-2.png|noframe|500px]] |
||
+ | ==Add File System Configuration Items for Pull Requests and Commits== |
||
− | == Configuring GitHub for PullRequests == |
||
+ | <p>Leave the GUI and go back to the file system </p> |
||
+ | <ol> |
||
+ | <li> Edit the github.properties file: |
||
+ | <ol> |
||
+ | <li> /HOME_DIR/docker/jenkins/lingoport/globalyzer-lite-VERSION/GitHub_PRC/github.properties. |
||
+ | <li> Update the github.login and github.oauth with the appropriate PAT values that were created ahead of time. |
||
+ | </li> |
||
+ | </ol> |
||
+ | <li> When using https there will need to be a .netrc file placed in the jenkins_home directory inside of the container. This can be placed in the volume directory at /HOME_DIR/docker/jenkins/.netrc |
||
+ | <ol> |
||
+ | <li> login <GitHub login ID> (Not email) |
||
+ | <li> password PAT |
||
+ | </li> |
||
+ | </ol> |
||
+ | <li> When using ssh there will need to be the ssh public and private keys stored in the /HOME_DIR/docker/jenkins/.ssh directory. Also with ssh be sure to manually connect to the git repo prior to using the PRC scripts. The known_hosts file needs to be updated and that is a manual process that requires manually accepting the key. This should only be needed to be performed once. |
||
+ | <li> Run the installer for Globalyzer-Lite. This must be done inside of the contains so everything is properly set up in that environment |
||
+ | <ol> |
||
+ | <li> Obtain the container id |
||
+ | <ol> |
||
+ | <li> <code> sudo docker container ps </code> |
||
+ | </li> |
||
+ | </ol> |
||
+ | <li> <code> sudo docker exec -it CONTAINER ID /bin/bash </code> |
||
+ | <li> <code> cd ~/lingoport/globalyzer-lite-VERSION </code> |
||
+ | <li> <code>./install-lite.sh </code> (Should return Globalyzer Lite installation completed successfully) |
||
+ | </li> |
||
+ | </ol> |
||
+ | </li> |
||
+ | </ol> |
||
+ | == Create Jenkins Build for Pull Requests and Commits via GitHub == |
||
− | Some configuration needs to be done on GitHub for the PullRequests to occur. |
||
− | In the GitHub page for your Project: |
||
<ol> |
<ol> |
||
− | <li> |
+ | <li> Log into Jenkins and go to the Dashboard |
− | <li>Select |
+ | <li> Select New Item |
+ | <li> Create an item name for the PRC build. |
||
− | <li>Select the '''Add webhook''' button. |
||
+ | <li> Use an item name that is memorable, something like GitHub-PRC is fine. |
||
+ | <li> Select Freestyle Project |
||
+ | <li> Select OK |
||
+ | <li> Add a description (optional) |
||
+ | <li> Select “This project is parameterized” |
||
+ | <li> Add two string parameters |
||
+ | <ol> |
||
+ | <li> payload = NOT_SET |
||
+ | <li> LITE_PROJECT_DEFINITION = DEFAULT |
||
+ | <ol> |
||
+ | <li> DEFAULT looks for the project definition to exist in the lingoport directory of the working branch as such: lingoport/LiteProjectDefinition.xml |
||
+ | </li> |
||
+ | </ol> |
||
+ | <li> Select “Throttle Concurrent Builds” |
||
+ | <ol> |
||
+ | <li> Set Maximum Total Concurrent Builds to 1 |
||
+ | <li> Set Maximum Concurrent Builds Per Node to 1 |
||
+ | </li> |
||
+ | </ol> |
||
+ | <li> In Build Triggers Section |
||
+ | <ol> |
||
+ | <li> Select Trigger builds remotely (e.g., from scripts) |
||
+ | <li> In the Authentication Token place a token you wish to use. Something like HOOK for example. |
||
+ | </li> |
||
+ | </ol> |
||
+ | <li> In Build Steps Section |
||
+ | <ol> |
||
+ | <li> Select Execute Shell |
||
+ | <li> Place the following shell code |
||
+ | <ul> |
||
+ | <li> <code> set +x </code> |
||
+ | <li> <code> $GITHUB_PRC_FILES/job_lite_pr.sh $GITHUB_PRC_FILES/pr_message.html </code> |
||
+ | </li> |
||
+ | </ul> |
||
+ | <li> In the Post-build Actions |
||
+ | <ol> |
||
+ | <li> Select Discard Old Builds |
||
+ | <li> Set Days to keep builds to 14 |
||
+ | </li> |
||
+ | </ol> |
||
+ | <li> Save the configuration |
||
+ | </li> |
||
+ | </ol> |
||
+ | </li> |
||
</ol> |
</ol> |
||
+ | === GitHub Configuration === |
||
+ | <p> |
||
− | [[File:webhook.png|800px]] |
||
+ | Webhooks are calls made from the GitHub side down to the Jenkins instance. They provide information required by the Jenkins build to properly scan the files that were either committed or had a pull request performed on them. This is discussed in detail in the Videos found in earlier sections of this page. |
||
+ | </p> |
||
+ | <p> |
||
+ | Below is a summary of the steps. |
||
+ | </p> |
||
<ol> |
<ol> |
||
+ | <li> Log into GitHub |
||
− | <li> Set the '''Payload URL''' to |
||
+ | <li> Navigate to the repository that will have pull requests and commits applied to it |
||
− | <pre>http://<Jenkins IP>:8080/buildByToken/buildWithParameters?job=<Group>.<Project>-PullRequest&token=HOOK</pre> |
||
+ | <li> Click on Settings → Webhooks→ Add webhook |
||
− | for PullRequest jobs or |
||
+ | <li> Enter the following: |
||
− | <pre>http://<Jenkins IP>:8080/buildByToken/buildWithParameters?job=<Group>.<Project>-DistributedPullRequest&token=HOOK</pre> for DistributedPullRequest jobs. |
||
+ | <ol> |
||
− | <li> Make sure the '''Content Type''' is <code>application/x-www-form-urlencoded</code> |
||
+ | <li> Payload URL |
||
− | <li> Leave '''Secret''' blank |
||
+ | <ol> |
||
− | <li> '''Which events would you like to trigger this webhook?''' Select: '''Let me select individual events''' and check the '''Pull Request''' item. |
||
+ | <li> URL found in Build Triggers Section of the Jenkins Build |
||
− | <li> Select '''Active'''. |
||
+ | <li> It will likely require the API Token generated prior along with the username that the build in Jenkins was created |
||
− | <li> '''Update''' or '''Add Webhook''' |
||
+ | <li> ht<span>tps://USER:TOKEN@JENKINS_URL/jenkins/job/BUILD_NAME/buildWithParameters?token=BUILD_TOKEN</span> |
||
+ | </li> |
||
+ | </ol> |
||
+ | <li> Content Type application/x-www-form-urlencoded |
||
+ | <li> Radio button: Let me select individual events |
||
+ | <ol> |
||
+ | <li> Pushes |
||
+ | <li> Pull Requests |
||
+ | <li> Pushes, Pull Requests |
||
+ | </li> |
||
+ | </ol> |
||
+ | </li> |
||
+ | </ol> |
||
+ | <li> Using the Recent Deliveries tab it's possible to check the status of a web hook call to confirm that it worked correctly. |
||
+ | <ol> |
||
+ | <li> There should be a build triggered for each webhook called submitted |
||
+ | <li> If there are issues use the Redeliver button to resend |
||
+ | </li> |
||
+ | </ol> |
||
+ | </li> |
||
</ol> |
</ol> |
||
+ | === Install Validation === |
||
− | If everything is correct, then after adding the Webhook, the Jenkins job <Group>.<Project>-PullRequest or <Group>.<Project>-DistributedPullRequest should be triggered. The job may FAIL, but at this point the verifying the communication between GitHub and the Jenkins job is a success. |
||
+ | <p> This completes the basic installation. To confirm that everything is working correctly. </p> |
||
− | |||
− | = Verify the PullRequest = |
||
− | To test that the Pull Request works, |
||
<ol> |
<ol> |
||
+ | <li> Log into GitHub and navigate to a repository |
||
− | <li> Use or create a new branch in the Git Project with changes to internationalization issues. |
||
+ | <li> Make a change directly to a file in the GitHub repository and “Commit” the change (assuming Commits are enabled). |
||
− | <li> In GitHub, select the '''Pull Requests''' tab |
||
+ | <li> Switch to Jenkins and confirm that the build was triggered and successfully completed |
||
− | <li> Select the '''New Pull Request''' button |
||
+ | <li> Switch back to GitHub and click on the commit id for the modification in and confirm that there is an associated summary. |
||
− | <li> Select the two branches you wish to compare. You should see the differences on the screen between the two branches. |
||
+ | <li> Clicking on the File/Line link in the summary should show the code line and modification made. |
||
− | <li> Select the '''Create New Pull Request''' button and enter a comment. |
||
+ | </li> |
||
− | <li> Select '''Create Pull Request''' |
||
</ol> |
</ol> |
||
+ | <br> |
||
− | Return to the Jenkins Pull Request job. It should be triggered and running. If it is successful, return to your Pull Request tab in GitHub and you should see something like: |
||
+ | |||
+ | <p> This is an image of the Analysis Summary in GitHub for a commit </p> |
||
+ | [[File:Intall-validation-1.png|noframe|500px]] |
||
+ | |||
+ | <br> |
||
+ | |||
+ | <p> This image shows the line of code that is presented when clicking on the link in the Analysis Summary </p> |
||
+ | [[File:Install-validation-2.png|noframe|500px]] |
||
+ | |||
+ | == SAML Integration (Optional) == |
||
+ | <p> |
||
+ | To optionally leverage SAML in place of the local user login system, follow the instructions found on this page |
||
+ | <p> |
||
+ | |||
+ | [[Docker Jenkins SAML Configuration]] |
||
+ | |||
+ | = Jenkins Upgrade when using Docker = |
||
+ | |||
+ | == Upgrade Required Indication == |
||
+ | |||
+ | When logging into Jenkins, there will be a message on the Manage Jenkins page indicating that a new version is available. |
||
+ | |||
+ | [[file:Before_Upgrade.png |800px]] |
||
+ | |||
+ | == Upgrade Procedure == |
||
+ | |||
+ | 1. Log into the VM containing docker with a user that has sudo privileges. |
||
+ | |||
+ | 2. Stop the existing jenkins/jenkins:lts-jdk17 container |
||
+ | sudo docker stop <CONTAINER ID> |
||
+ | |||
+ | 3. Make a backup of the existing Jenkins directory that is mounted as a volume. All Jenkins files are contained on the file system, there is no associated DB. |
||
+ | $ cp -pr /home/<USER_DIR>/docker/jenkins /home/USER_DIR/docker/jenkins_<MMDDYYYY> |
||
+ | |||
+ | 4. Pull the latest version of the jenkins/jenkins:lts-jdk17 from docker.io. Note that it will indicate a newer image has been downloaded. |
||
+ | sudo docker pull jenkins/jenkins:lts-jdk17 |
||
+ | lts-jdk17: Pulling from jenkins/jenkins |
||
+ | bd73737482dd: Pull complete |
||
+ | 747b9186aa97: Pull complete |
||
+ | 77e4b3fa9f98: Pull complete |
||
+ | 4185da018337: Pull complete |
||
+ | fbfe8a536a91: Pull complete |
||
+ | c28d8031aee7: Pull complete |
||
+ | d90093f5fc84: Pull complete |
||
+ | b7bf9221df23: Pull complete |
||
+ | 22a3392c99b4: Pull complete |
||
+ | bbe8cad20a08: Pull complete |
||
+ | c81331c127c6: Pull complete |
||
+ | c125b4d0161b: Pull complete |
||
+ | da080ad7c1d0: Pull complete |
||
+ | Digest: sha256:90f7f78a7e114516216b6c0a06e00c597d6490597caec9d7bd7a95ce5c7dada0 |
||
+ | Status: Downloaded newer image for jenkins/jenkins:lts-jdk17 |
||
+ | docker.io/jenkins/jenkins:lts-jdk17 |
||
+ | |||
+ | 5. Start the new container with the updated image using one of the two options below depending upon whether a proxy is required to be leveraged from inside of the container or not. Adjust the home directory location as needed for the particular installation. |
||
+ | |||
+ | '''Option #1''' - Run the newly updated container to start Jenkins with the latest |
||
+ | version (Command is the same as the one used initially to run) |
||
+ | |||
+ | $ sudo docker run -d -u 1000:1000 -p 8085:8080 -p 50000:50000 \ |
||
+ | --env JENKINS_OPTS="--prefix=/jenkins" \ |
||
+ | --restart=unless-stopped \ |
||
+ | -v /home/centos/docker/jenkins:/var/jenkins_home jenkins/jenkins:lts-jdk17 |
||
+ | $ |
||
+ | $ sudo docker container ls |
||
+ | CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES |
||
+ | 1924e0a6bf0d jenkins/jenkins:lts-jdk17 "/usr/bin/tini -- /u…" 2 minutes ago Up 2 minutes 0.0.0.0:50000->50000/tcp, :::50000->50000/tcp, 0.0.0.0:8085->8080/tcp, :::8085->8080/tcp peaceful_snyder |
||
+ | |||
+ | '''Option #2''' - Run the newly updated container to start Jenkins with |
||
+ | the latest version of Jenkins when a proxy is needed for outgoing communications |
||
+ | version (Command is the same as the one used initially to run) |
||
+ | |||
+ | $ sudo docker run -d -u 1000:1000 -p 8085:8080 -p 50000:50000 \ |
||
+ | --env JENKINS_OPTS="--prefix=/jenkins" \ |
||
+ | --env http_proxy="http://<PROXY_URL>:<PORT>" \ |
||
+ | --env https_proxy="http://<PROXY_URL>:<PORT>" \ |
||
+ | --restart=unless-stopped \ |
||
+ | -v /home/centos/docker/jenkins:/var/jenkins_home jenkins/jenkins:lts-jdk17 |
||
+ | $ |
||
+ | $ sudo docker container ls |
||
+ | CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES |
||
+ | 9e2650b5ec1c jenkins/jenkins:lts-jdk17 "/usr/bin/tini -- /u…" 33 seconds ago Up 32 seconds 0.0.0.0:50000->50000/tcp, :::50000->50000/tcp, 0.0.0.0:8085->8080/tcp, :::8085->8080/tcp elegant_engelbart |
||
+ | |||
+ | |||
+ | 6. Confirm that the new version is running properly by logging in the web interface and going to the manage jenkins section. There should not be mention of a new version being available. |
||
+ | |||
+ | [[file:After_Upgrade.png |800px]] |
||
+ | |||
+ | 7. At the bottom of this page, the current version will be displayed in the footer. |
||
+ | |||
+ | 8. The old container can be removed if desired at this point. |
||
+ | sudo docker rm <CONTAINER ID> |
||
+ | |||
+ | 9. The old image can also be removed if desired at this point. |
||
+ | sudo docker rmi <IMAGE ID> |
||
+ | |||
+ | 10. The system will now be running the latest version of the Jenkins docker image and both the old images and containers will have been removed. |
||
+ | |||
+ | = Historical Version of the Pull Request/Commit Globalyzer Scanning = |
||
+ | [[ Historical Pull Request | Historical Pull Request ]] |
||
− | [[File:Pulltest.png|800px]] |
Latest revision as of 17:30, 30 October 2024
Contents
- 1 Introduction
- 2 Video Introduction to GitHub, GitLab, and Bitbucket
- 3 Pull Requests via Jenkins Running on Docker
- 3.1 Prerequisites
- 3.2 File System Configuration
- 3.3 Launching the Jenkins Docker Container
- 3.4 Browser Connected Configuration
- 3.5 Add GUI Configuration Items for Pull Requests and Commits
- 3.6 Add File System Configuration Items for Pull Requests and Commits
- 3.7 Create Jenkins Build for Pull Requests and Commits via GitHub
- 3.8 SAML Integration (Optional)
- 4 Jenkins Upgrade when using Docker
- 5 Historical Version of the Pull Request/Commit Globalyzer Scanning
Introduction
For GitHub, GitLab and Bitbucket, commits, Pull Requests / Merge Requests code changes can be analyzed using the Globalyzer Scanner.
A Webhook lets a Jenkins job know to scan the code committed. Only the code modified is analyzed by the Globalyzer scanner. The result is a comment in GitHub, GitLab or Bitbucket showing issues detected.
In the example below, one line was modified and the Globalyzer scan shows an i18n issue. The developer can decide how to handle it.
This is unobtrusive and provides actionable i18n information to developers.
Video Introduction to GitHub, GitLab, and Bitbucket
Below are short introductions of the functionality around Globalyzer scanning for Git repository:
- GitHub https://vimeo.com/817611647
- GitLab https://vimeo.com/817610534
- Bitbucket https://vimeo.com/826230267
Pull Requests via Jenkins Running on Docker
Prerequisites
- VM running Linux and Docker
- JQ JSON Parser - Statically compiled binary version
- GitHub PAT credentials to connect to GitHub
- The user for these PAT credentials has read access to the repository
- Globalyzer.com credentials for logging in to globalyzer.com
- username
- password
- Obtain a copy of Globalyzer Lite from https://www.globalyzer.com/gzserver/home/installclient (requires Globalyzer.com credentials)
- A copy of your Globalyzer.license from globalyzer.com or your local globalyzer server instance.
- Jenkins will use the following URL to download all plugins required during the installation. This URL is required to be reachable from the VM Jenkins is being installed on prior to starting the install.
- Optional:
- Apache or nginx could be installed and running on the VM itself as a reverse proxy to front the Jenkins instance
File System Configuration
If Apache is installed as per normal for many Lingoport systems, the following is required to configure Apache to permit proper connection to the Jenkins Docker container
- Create the directory structure for the volume storage used by jenkins. Be sure there is sufficient space. Base install will consume 650MB of space for the volume itself.
- Place the Globalyzer License into the lingoport directory created
- Copy the downloaded copy of Globalyzer Lite into the lingoport directory
- Copy the jq binary into the bin directory and set the permissions
- Unzip the Globalyzer Lite zip file in the lingoport directory and remove the zip file once complete
- Create the .globalyzerrc file in the jenkins home directory, add the proper credentials and set the permissions
- Confirm the contents of the .globalyzerrc file are entered like this: (Note no equals or colon, just whitespace between key and value)
mkdir ~/docker/jenkins/lingoport/bin
cp ~/PRC-Docker/Globalyzer.license ~/docker/jenkins/lingoport/
cp ~/PRC-Docker/globalyzer-lite-VERSION.zip ~/docker/jenkins/lingoport/
cp -p ~/PRC-Docker/jq ~/docker/jenkins/lingoport/bin/
chmod +x ~/docker/jenkins/lingoport/bin/jq
cd ~/docker/jenkins/lingoport
unzip globalyzer-lite-VERSION.zip
rm ./globalyzer-lite-VERSION.zip
vi .globalyzerrc
chmod 600 .globalyzerrc
username <GLOBALYZER LOGIN USERNAME>
password <GLOBALYZER LOGIN PASSWORD>
server <URL of Globalyzer Server>
Launching the Jenkins Docker Container
Retrieve these two items as they are now required to proceed
- Obtain the UID and GID for the user that Docker is being ran by.
- Identify the the port that Jenkins should be listening on.
- In the example below it was determined to be 8085
The next command line is an example of what would be used to start the docker instance for Jenkins. Here is an explanation of the switches being used when no proxy is required for the container to reach required destinations.
The command string will create a new container instance that will automatically restart the container unless specifically stopped. It will also reuse the existing container on a restart of the OS. If the container is stopped before the reboot is performed using sudo docker stop "CONTAINTER ID" , it will need to be started using sudo docker start "CONTAINER ID"
- The -d detaches the command being run from the terminal. Normally this is something that will only be used once everything is in place and confirmed to be working. For initial startup, its use can be ignored.
- The -u is for setting the uid/gid of the user that owns the volume storage identified earlier. This user should also be the user that is starting the docker instance.
- The -p 8085:8080 is the port external to internal mapping identified earlier. The 8080 would never change, only the external port is modifiable
- The -p 50000:50000 is for mapping between Jenkins instances only. Not required for standalone systems.
- The JENKINS_OPTS sets the baseurl for the application
- The -v mounts the prior locally created file system to the running docker instance as a volume and mas it.
- The jenkins/jenkins:lts-jdk17 is the long term support image for Jenkins. Currently, it is Jenkins 2.452.2
sudo docker run -d -u 1000:1000 -p 8085:8080 -p 50000:50000 \
--env JENKINS_OPTS="--prefix=/jenkins" --restart=unless-stopped \
-v /USER_HOME_DIR/docker/jenkins:/var/jenkins_home jenkins/jenkins:lts-jdk17
If a proxy is required to be leveraged by the container to reach destinations the next command line would be used to start the docker instance for Jenkins instead of the previous one. Note the additional env variables that are added to support the proxy.
sudo docker run -d -u 1000:1000 -p 8085:8080 -p 50000:50000 \
--env JENKINS_OPTS="--prefix=/jenkins" \
--env http_proxy="http://<PROXY_URL>:<PORT>" \
--env https_proxy="http://<PROXY_URL>:<PORT>" \
--restart=unless-stopped \
-v /home/centos/docker/jenkins:/var/jenkins_home jenkins/jenkins:lts-jdk17
This will download the required images and start the container. There will be a message about initial password, make note of it as it will be used to log into Jenkins
*************************************************************
*************************************************************
*************************************************************
Jenkins initial setup is required. An admin user has been created and a password generated.
Please use the following password to proceed to installation:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
This may also be found at: /var/jenkins_home/secrets/initialAdminPassword
*************************************************************
*************************************************************
*************************************************************
Browser Connected Configuration
Go to application using the browser and use the above password to log in initially
At this screen select Install Suggested Plugins
The plugins will begin to install, this will only be a few minutes.
Create the Admin account. This will be a new account outside of what was used to connect initially. It will be the administrator account.
This sets up the URL with a path to the instance. It will include /jenkins so it should be something like “http(s)://<YOUR FQDN/jenkins/
The base Jenkins system install is complete at this point.
Click Start using Jenkins and the Dashboard appears
The alert is caused by this running locally and not using nodes. Click on it and select “Dismiss”
If once this is cleared, this message appears. It is due to a reverse proxy being used that needs to have some additional configuration.
When using Apache as a reverse proxy, adding these two entries to the virtual host SSL configuration should correct the error.
RequestHeader set X-Forwarded-Proto "https"
RequestHeader set X-Forwarded-Port "443"
Add GUI Configuration Items for Pull Requests and Commits
Install and additional plugin called “Discard Old Builds” by going to Manage Jenkins → Manage Plugins → Available Plugins and search for “Discard old builds”
Install an additional plugin called “Throttle Concurrent Builds” by going to Manage Jenkins → Manage Plugins → Available Plugins and search for “Throttle Concurrent Builds”
Once plugin is installed to go Manage Jenkins → Configure System → Throttle Concurrent Builds and select Add Category:
Create Category Name PRC_THROTTLE and set Maximum Total Concurrent Builds = 1 and Maximum Concurrent Builds Per Node = 1.
Select “Apply” to save
Set up the environment variables in Jenkins:
- Select the Environment Variables checkbox
- Select Add and add the following
- For a GitHub Installation
- GITHUB_PRC_FILES = $JENKINS_HOME/lingoport/<globalyzer-lite-dir>/GitHub_PRC
- PATH = $PATH:$JENKINS_HOME/lingoport/bin
- If https is to be used for connecting to the git repos set to true. If ssh is to be used to connect to git repos set to false.
- useHTTPS = true or false
- Optional - If Proxy is required:
- Add entry _JAVA_OPTIONS with proxy details as shown in screenshot below
- Dhttp.proxyHost=<FQDN> Dhttp.proxyPort=<PORT> Dhttps.proxyHost=<FQDN> Dhttps.proxyPort=<PORT>
- For a GitHub Installation
Click Apply and Save
Add new API token to be used by GitHub Webhook
In Jenkins create a new API token for the user that will be running the build. This will be required to be added to the webhook to permit connection back to the Jenkins instance
The credentials used for GitHub will require read access to the git repository.
- Select Dashboard → Manage Jenkins → Manage Users → Select the gear icon on the right side of the Admin user (Admin user created earlier)
- In the API Token section, select Add new Token
- Set the name of the new token to GitHub-PRC-TOKEN or something that is memorable and can identify with the PRC action.
- Be sure to copy the token value as it will never be displayed beyond this time.
Add File System Configuration Items for Pull Requests and Commits
Leave the GUI and go back to the file system
- Edit the github.properties file:
- /HOME_DIR/docker/jenkins/lingoport/globalyzer-lite-VERSION/GitHub_PRC/github.properties.
- Update the github.login and github.oauth with the appropriate PAT values that were created ahead of time.
- When using https there will need to be a .netrc file placed in the jenkins_home directory inside of the container. This can be placed in the volume directory at /HOME_DIR/docker/jenkins/.netrc
- login <GitHub login ID> (Not email)
- password PAT
- When using ssh there will need to be the ssh public and private keys stored in the /HOME_DIR/docker/jenkins/.ssh directory. Also with ssh be sure to manually connect to the git repo prior to using the PRC scripts. The known_hosts file needs to be updated and that is a manual process that requires manually accepting the key. This should only be needed to be performed once.
- Run the installer for Globalyzer-Lite. This must be done inside of the contains so everything is properly set up in that environment
- Obtain the container id
-
sudo docker container ps
-
-
sudo docker exec -it CONTAINER ID /bin/bash
-
cd ~/lingoport/globalyzer-lite-VERSION
-
./install-lite.sh
(Should return Globalyzer Lite installation completed successfully)
- Obtain the container id
Create Jenkins Build for Pull Requests and Commits via GitHub
- Log into Jenkins and go to the Dashboard
- Select New Item
- Create an item name for the PRC build.
- Use an item name that is memorable, something like GitHub-PRC is fine.
- Select Freestyle Project
- Select OK
- Add a description (optional)
- Select “This project is parameterized”
- Add two string parameters
- payload = NOT_SET
- LITE_PROJECT_DEFINITION = DEFAULT
- DEFAULT looks for the project definition to exist in the lingoport directory of the working branch as such: lingoport/LiteProjectDefinition.xml
- Select “Throttle Concurrent Builds”
- Set Maximum Total Concurrent Builds to 1
- Set Maximum Concurrent Builds Per Node to 1
- In Build Triggers Section
- Select Trigger builds remotely (e.g., from scripts)
- In the Authentication Token place a token you wish to use. Something like HOOK for example.
- In Build Steps Section
- Select Execute Shell
- Place the following shell code
-
set +x
-
$GITHUB_PRC_FILES/job_lite_pr.sh $GITHUB_PRC_FILES/pr_message.html
-
- In the Post-build Actions
- Select Discard Old Builds
- Set Days to keep builds to 14
- Save the configuration
GitHub Configuration
Webhooks are calls made from the GitHub side down to the Jenkins instance. They provide information required by the Jenkins build to properly scan the files that were either committed or had a pull request performed on them. This is discussed in detail in the Videos found in earlier sections of this page.
Below is a summary of the steps.
- Log into GitHub
- Navigate to the repository that will have pull requests and commits applied to it
- Click on Settings → Webhooks→ Add webhook
- Enter the following:
- Payload URL
- URL found in Build Triggers Section of the Jenkins Build
- It will likely require the API Token generated prior along with the username that the build in Jenkins was created
- https://USER:TOKEN@JENKINS_URL/jenkins/job/BUILD_NAME/buildWithParameters?token=BUILD_TOKEN
- Content Type application/x-www-form-urlencoded
- Radio button: Let me select individual events
- Pushes
- Pull Requests
- Pushes, Pull Requests
- Payload URL
- Using the Recent Deliveries tab it's possible to check the status of a web hook call to confirm that it worked correctly.
- There should be a build triggered for each webhook called submitted
- If there are issues use the Redeliver button to resend
Install Validation
This completes the basic installation. To confirm that everything is working correctly.
- Log into GitHub and navigate to a repository
- Make a change directly to a file in the GitHub repository and “Commit” the change (assuming Commits are enabled).
- Switch to Jenkins and confirm that the build was triggered and successfully completed
- Switch back to GitHub and click on the commit id for the modification in and confirm that there is an associated summary.
- Clicking on the File/Line link in the summary should show the code line and modification made.
This is an image of the Analysis Summary in GitHub for a commit
This image shows the line of code that is presented when clicking on the link in the Analysis Summary
SAML Integration (Optional)
To optionally leverage SAML in place of the local user login system, follow the instructions found on this page
Docker Jenkins SAML Configuration
Jenkins Upgrade when using Docker
Upgrade Required Indication
When logging into Jenkins, there will be a message on the Manage Jenkins page indicating that a new version is available.
Upgrade Procedure
1. Log into the VM containing docker with a user that has sudo privileges.
2. Stop the existing jenkins/jenkins:lts-jdk17 container
sudo docker stop <CONTAINER ID>
3. Make a backup of the existing Jenkins directory that is mounted as a volume. All Jenkins files are contained on the file system, there is no associated DB.
$ cp -pr /home/<USER_DIR>/docker/jenkins /home/USER_DIR/docker/jenkins_<MMDDYYYY>
4. Pull the latest version of the jenkins/jenkins:lts-jdk17 from docker.io. Note that it will indicate a newer image has been downloaded.
sudo docker pull jenkins/jenkins:lts-jdk17 lts-jdk17: Pulling from jenkins/jenkins bd73737482dd: Pull complete 747b9186aa97: Pull complete 77e4b3fa9f98: Pull complete 4185da018337: Pull complete fbfe8a536a91: Pull complete c28d8031aee7: Pull complete d90093f5fc84: Pull complete b7bf9221df23: Pull complete 22a3392c99b4: Pull complete bbe8cad20a08: Pull complete c81331c127c6: Pull complete c125b4d0161b: Pull complete da080ad7c1d0: Pull complete Digest: sha256:90f7f78a7e114516216b6c0a06e00c597d6490597caec9d7bd7a95ce5c7dada0 Status: Downloaded newer image for jenkins/jenkins:lts-jdk17 docker.io/jenkins/jenkins:lts-jdk17
5. Start the new container with the updated image using one of the two options below depending upon whether a proxy is required to be leveraged from inside of the container or not. Adjust the home directory location as needed for the particular installation.
Option #1 - Run the newly updated container to start Jenkins with the latest version (Command is the same as the one used initially to run)
$ sudo docker run -d -u 1000:1000 -p 8085:8080 -p 50000:50000 \ --env JENKINS_OPTS="--prefix=/jenkins" \ --restart=unless-stopped \ -v /home/centos/docker/jenkins:/var/jenkins_home jenkins/jenkins:lts-jdk17 $ $ sudo docker container ls CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 1924e0a6bf0d jenkins/jenkins:lts-jdk17 "/usr/bin/tini -- /u…" 2 minutes ago Up 2 minutes 0.0.0.0:50000->50000/tcp, :::50000->50000/tcp, 0.0.0.0:8085->8080/tcp, :::8085->8080/tcp peaceful_snyder
Option #2 - Run the newly updated container to start Jenkins with the latest version of Jenkins when a proxy is needed for outgoing communications version (Command is the same as the one used initially to run)
$ sudo docker run -d -u 1000:1000 -p 8085:8080 -p 50000:50000 \ --env JENKINS_OPTS="--prefix=/jenkins" \ --env http_proxy="http://<PROXY_URL>:<PORT>" \ --env https_proxy="http://<PROXY_URL>:<PORT>" \ --restart=unless-stopped \ -v /home/centos/docker/jenkins:/var/jenkins_home jenkins/jenkins:lts-jdk17 $ $ sudo docker container ls CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 9e2650b5ec1c jenkins/jenkins:lts-jdk17 "/usr/bin/tini -- /u…" 33 seconds ago Up 32 seconds 0.0.0.0:50000->50000/tcp, :::50000->50000/tcp, 0.0.0.0:8085->8080/tcp, :::8085->8080/tcp elegant_engelbart
6. Confirm that the new version is running properly by logging in the web interface and going to the manage jenkins section. There should not be mention of a new version being available.7. At the bottom of this page, the current version will be displayed in the footer.
8. The old container can be removed if desired at this point.
sudo docker rm <CONTAINER ID>
9. The old image can also be removed if desired at this point.
sudo docker rmi <IMAGE ID>
10. The system will now be running the latest version of the Jenkins docker image and both the old images and containers will have been removed.
Historical Version of the Pull Request/Commit Globalyzer Scanning