I know there were a lot of conversations to this topic but any of those was helpful to me. So what I'm doing is configuring Jenkins CI to work properly with Github.
We want next:
When someone creates new PR or add commit to existing PR, Github
triggers Jenkins build.
During build is processing we want to see status - pending
Merge button should be disabled till build is completed
After build is completed, we want to see what is the status of that build - successful or failed
Right now, only step 1 works correctly but we can't figure out what is the problem with Jenkins requests to Github!
Also in console output I see error:
ERROR: Build step failed with exception java.lang.IllegalStateException: Can't get remote GH repo for project1 build and don't know what is the problem.
Any help would be really appreciated !
Regards
If you are using GitHub Pull Request Builder , go to trigger setup -> Update commit status during build
Related
The idea is that I want to block pull requests on GitHub if a build fails on Jenkins so that potential bad code doesn't get merged
I had originally found a plugin called Pipeline GitHub Notify Step: https://www.jenkins.io/doc/pipeline/steps/pipeline-githubnotify-step/ that uses
githubNotify
but then I found out from this link https://plugins.jenkins.io/pipeline-githubnotify-step/ that we should use the github-checks-plugin instead of the Pipeline GitHub Notify. I don't know if its because its depreciated or they just added similar features to the github-checks-plugin but I decided to just install the GitHub Checks Plugin. Afterwards I opened a PR on GitHub with code I knew would fail the build then ran a test build on Jenkins with the impression that GitHub would block my PR due to the bad build but it didn't I went under settings->branch and enabled Require status checks to pass before merging but it didn't block my PR because of the failed build. In fact it still doesn't even notice the failed build. Maybe I'm missing another plugin or perhaps there was something I forgot to enable.
The Jenkins build was successful but when I add the Jenkins build link GitHub Pull Request description. It's showing the the last Jenkins build Link failed.
Any Idea what causes the error?
We are using Travis-CI to test our project (Speedy Net). A test failed and I want to rebuild it. I checked this answer but it doesn't work for me. This changed recently. I'm the owner of this organization on GitHub but on Travis CI I'm not a member of any organization. On this build's page I don't have any rebuild button. What can I do to be able to rebuild this test?
Travis CI for Open Source
It works now (after my login expired and I logged in again). When Travis CI login via GitHub expires, it's not possible to rebuild tests.
It depends, if the test is triggered via a pull request then it is as simple as closing then reopening that pull request.
If you are triggering the test in another way then do that thing again, e.g. push --force-with-lease, commit --allow-empty, etc. to restart the process.
Basically if a build fails because for example, a host is unreachable temporarily in the test/build setup rather than any issue with the code, then trigger the build again in the same way you did originally.
We are using Github + CircleCI + Heroku with automatic deploys setup.
From time to time there are deploy errors that are not captured by CI (deployment fails event though CI run is fine). We have review apps set up for all our PRs.
It would be great if the PR would indicate this and stop us from merging if the deployment of the review app fails (that usually means the deployment of the staging/production app would also fail).
I could not find any documentation on this. The only possible way I see is to use the GitHub API to add a custom check for this.
Anyone solved this issue?
We have made a GitHub Action to test the deployment status of a Heroku Review App: https://github.com/marketplace/actions/heroku-review-app-deployment-status.
This can be used in the GitHub workflow to test the deployment status.
UPDATE: We wrote a nice blog post about different approaches to verify Review App deployment status.
Link: https://blog.niteo.co/staging-like-its-2020/
You can use Github's protected branches for this https://help.github.com/en/articles/enabling-required-status-checks
Navigate to your repository's settings -> Branches -> Add Protection Rule -> Select "Require Status Checks Before Merging" and select "CircleCI".
In order for this to work you need to cause CI to fail if your deployment fails. If you get a failure from Heroku, you should run any command that will return exit 1 as a status code, which will fail CI for you.
Almost breaking my head over this for last few days but the github plugin for sonarqube (v 5.3) just does not seem to work.
I have my java app code in github, and have configured Jenkins to run mvn sonar:sonar goal on pull request.
The maven settings are:
clean site sonar:sonar
-Dsonar.analysis.mode=preview
-Dsonar.github.oauth=<OAUTH_TOKEN>
-Dsonar.github.repository=<ORG>/<REPO>
-Dsonar.github.pullRequest=${ghprbPullId}
-Dsonar.github.endpoint=<ENT_GITHUB_API_BASE__URI>
For sonar.analysis.mode, I tried 'issues' too
Now I perform foll:
make change to a fork (introduce a violation as per configured quality gate)
commit and push to fork repo
Create a pull request
run the jenkins job using above configuration
The analysis is successful, and the plugin always reports that all checks have passed and changes can be merged. I am just not able to understand why the github plugin in sonar is not able to show violation occured and checks have failed.
Now if I merge the pull request and run sonar analysis in publish mode on the master repo, it says quality gate failed and I am able to see this in SonarQube dashboard for the project with the statement that Quality gate has failed
What am I doing wrong here? My guess is the github plugin not able to compare the changes in the pull request with that in the master repo and hence not able to report the violation. How do I fix that?
Update:
If at the end, I merge the pull request to master repo and re-run the sonar analysis on the original pull request (the one that got merged), it does report the violation as comments in the Pull Request conversation. (But what is the point if sonar is going to report the violations after the pull request is merged???)