Difference between revisions of "GitHub Pull Requests"
(→Running the Analysis) |
|||
| Line 5: | Line 5: | ||
Files can be committed in a Git branch or directly in Master. 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. |
Files can be committed in a Git branch or directly in Master. 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. |
||
| + | You can configure Globalyzer to scan the files that changed between the two branches of the pull request, and post a Globalyzer Analysis Summary on the pull request in Github. |
||
== Example of a Pull Request Analyzed with Globalyzer == |
== Example of a Pull Request Analyzed with Globalyzer == |
||
| Line 67: | Line 68: | ||
* Test the Web hook and especially check for firewall issues going back to the Jenkins system |
* Test the Web hook and especially check for firewall issues going back to the Jenkins system |
||
| − | |||
| − | === Sample sonar-project.properties file: === |
||
| − | |||
| − | For instance, here is a test sonar-project.properties with some properties modified for security reasons: |
||
| − | <pre> |
||
| − | sonar.projectKey=Lingoport.indexing2:scan |
||
| − | sonar.projectName=Lingoport.indexing2 |
||
| − | sonar.projectVersion=5.1 |
||
| − | sonar.sources=C:/Users/Joe/Documents/GitHub/indexing2 |
||
| − | sonar.importSources=true |
||
| − | sonar.lingoport.project.root=. |
||
| − | sonar.language=lport |
||
| − | |||
| − | #sonar.lingoport.extensions=as,mxml,asp,asax,ascx,ashx,aspx,awk,c,c++,cc,cpp,cxx,h,hpp,hxx,sqc,sqx,qml,cs,dfm,dpk,dpr,pas,java,jsp,jspf,js,perl,pl,pm,plx,inc,php,sql,sqc,sqx,bas,cls,ctl,dob, |
||
| − | dsr,frm,pag,vb,vbs,htm,html,shtml,vm,html5,xml,xsd,xsl,xslt,wsdl,wsdd,rmd,tld,xliff,xul,xhtml,mxml,jspx,xaml,css,cat,resx,msg,po,properties,rc,rc2,strings,json,ts,rxml,rjs,properties |
||
| − | |||
| − | # |
||
| − | # For the GitHub SonarQube Plugin |
||
| − | # |
||
| − | sonar.analysis.mode=preview |
||
| − | sonar.github.login=ursulaLingoport |
||
| − | sonar.github.oauth=d60bbe9d6d3c7caa995f5119ff2997b26d0ef191 |
||
| − | sonar.github.repository=ursulaLingoport/indexing2 |
||
| − | sonar.github.pullRequest=6 |
||
| − | sonar.github.disableInlineComments=true |
||
| − | </pre> |
||
| − | |||
| − | ===Sonar-Runner and GlobalyzerLite Paths/Aliases=== |
||
| − | Instead of having to call the path of your respective program/script each time (I.E. - <code>java -jar "C:\lingoport\globalyzer-lite-4.8.5\globalyzer-lite.jar" GzProjectDefinition.xml</code>), you can create command-line aliases to run these commands quickly and more efficiently (I.E. - <code>lite GzProjectDefinition.xml</code>) |
||
| − | |||
| − | ====Windows==== |
||
| − | *Create an alias for GlobalyzerLite (running the doskey command is a quick way to create an alias on windows) |
||
| − | **<code>doskey lite=java -jar C:\lingoport\globalyzer-lite-4.8.5\globalyzer-lite.jar</code> |
||
| − | *Add sonar-runner to your path if you have not already, to allow the scanner to be run within any directory with the simple command <code>sonar-runner</code> |
||
| − | **<code>set PATH=%PATH%;C:\path\to\sonar-scanner-2.5.1</code> |
||
| − | |||
| − | ====Unix==== |
||
| − | *Create an alias for GlobalyzerLite (this command adds the alias to the end of your .bashrc file) |
||
| − | **<code>echo 'alias lite="java -jar /destination/to/globalyzer-lite-5.0/globalyzer-lite.jar" ' >> ~/.bashrc</code> |
||
| − | *Add sonar-runner to your path if you have not already, to allow the scanner to be run within any directory with the simple command <code>sonar-runner</code> |
||
| − | **<code>echo 'export PATH=$PATH:/etc/sonar-scanner-2.5.1/bin' >> ~/.bashrc</code> |
||
| − | |||
| − | |||
| − | ===Globalyzer Lite Project Definition File=== |
||
| − | In order to successfully scan the project directory for analysis, the <code>ProjectDefinition.xml</code> file needs to be correctly configured in your project's root directory. |
||
| − | :[https://www.globalyzer.com/gzserver/help/referenceLite/project-definition-file-overview.html For help on this setup, click here.] |
||
| − | |||
| − | == Running the Analysis == |
||
| − | * Checkout code from a branch (not master) or create a new branch |
||
| − | **<code> git checkout <-b> workingBranchName </code> (use the -b flag to create a new branch) |
||
| − | * Modify the code in your working branch |
||
| − | * Add, commit & push the code to the branch (not master) |
||
| − | ** <code>git add .</code> |
||
| − | ** <code>git commit -am "Commit Message"</code> |
||
| − | ** <code>git push origin workingBranchName </code> |
||
| − | * Create a pull request on GitHub.com (your working branch --> master) |
||
| − | * Run a couple of commands: |
||
| − | ** <code>java -jar "c:\lingoport\globalyzer-lite-4.8.5\globalyzer-lite.jar" GzProjectDefinition.xml</code> or <code>lite GzProjectDefinition.xml</code> (if you set an alias) |
||
| − | ** <code>C:\sonar\sonar-runner-2.4-local\bin\sonar-runner</code> or <code>sonar-runner</code> (if you added sonar-runner to the machines PATH) |
||
| − | * Check the pull request comments on GitHub: The i18n issues found on the code in the pull request will be shown. |
||
| − | |||
| − | :::<b>Note</b>: The command <code>java -jar "c:\lingoport\globalyzer-lite-4.8.5\globalyzer-lite.jar" GzProjectDefinition.xml</code> is used to create a Globalyzer report under the directory <code>GlobalyzerScans</code>. It could be any commands to create that Globalyzer report. The sonar-runner then needs to be executed from above the <code>GlobalyzerScans</code> directory. |
||
| − | |||
| − | == Additional Information == |
||
| − | http://stackoverflow.com/questions/32047585/jenkins-sonar-github-integration |
||
Revision as of 16:28, 27 November 2019
Contents
GitHub
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.
Git Pull Requests
Files can be committed in a Git branch or directly in Master. 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.
You can configure Globalyzer to scan the files that changed between the two branches of the pull request, and post a Globalyzer Analysis Summary on the pull request in Github.
Example of a Pull Request Analyzed with Globalyzer
This is pull request #44. The change to the code in the pull request was to add multiple embedded strings and a locale-sensitive method to the files ExampleMain.java & ExamplePanel.java. This pull request is reporting 25 different issues, however since the sonar-project.properties attribute is set to sonar.github.disableInlineComments=true, the top ten issues (sorted by severity, by component, then by line) are put into a summary analysis as a pull request comment.
Globalyzer analysis flagged these lines as critical issues. Clicking on the link next to the issue number will send the user to the line of code in that respective file.
Before merging the code back to master, the developer would typically externalize these strings, fix the locale-sensitive method issue, and re-submit the changed code / resource files for further analysis.
Pull Request Analysis Configuration
Configure github.properties
Create Jenkins Job for Pull Request
Create Web Hook for Github Repository
Globalyzer Dashboard uses the SonarQube sonar-project.properties file for configuration. This file should be in your repositories base directory. For the i18n analysis of the pull request, the sonar-project.properties file needs the following attributes:
sonar.analysis.mode=preview- It is imperative this attribute is set to preview to work. If not set, it defaults to publish mode, and could create future issues for analysis on this pull request.
sonar.github.login=- Your GitHub login name
sonar.github.oauth=- GitHub oauth is your unique GitHub personal access token: created @ https://github.com/settings/tokens
sonar.github.repository=- The repository you are working in. If repository link is https://github.com/ursulaLingoport/indexing2, this attribute should be set to
sonar.github.repository=ursulaLingoport/indexing2
- The repository you are working in. If repository link is https://github.com/ursulaLingoport/indexing2, this attribute should be set to
sonar.github.pullRequest=- The number of the pull request you plan to run an i18n analysis on.
sonar.github.disableInlineComments=- If set to true (highly recommended), issues will not be reported as inline comments but only in the global analysis summary in sorted order. False by default.
- This Wiki page is based around this attribute being set to true. Here is an example of a Pull Request when this attribute is set to false (issues appear as individual inline comments within the pull request).
GitHub Personal Access Token Security
Since the sonar-project.properties file includes a personal access token (OAuth), this file cannot be pushed to a remote repository. This exposes the users personal access token to the public, and therefore will void the token. If this happens, you should receive an email from GitHub acknowledging the user of the exposure and the token's decommission. In order to avoid this, the user must avoid staging the sonar-project.properties file for commit. In order to do this, you can create a .gitignore file in your repository's root directory to ignore all files with the .properties extension. It is recommended to do this in your master branch, so all forked and branched repositories will not face this issue.
Here is an example .gitignore file that will prevent this issue from occurring:
GitHub WebHook
The Pull Request on GitHub needs to trigger a Web hook back to Lingoport's Jenkins instance. To do so:
- Navigate to the GitHub repository as an Admin account
- In Settings tab for the GitHub repository (available if the account has Admin permissions), add a Webhook
- The Web hook should follow this pattern:
Payload URL: http(s)://JENKINS_URL/jenkins/buildByToken/buildWithParameters/build?job=RepoName-PullRequest&token=HOOK
Content type: application/x-www-form-urlencoded
Pull Request event selected
Active
For example:
- Test the Web hook and especially check for firewall issues going back to the Jenkins system
