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.
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.
Our Company used to self-host GitLab for source-code management and configured webhook on gitlab to trigger all the project pipelines on jenkins. Initially, the gitlab url was 'https://git.fulcrumdigital.com' and later for an upgraded version, they changed url to 'https://autobuild.fulcrumdigital.com'
Recently, we migrated to 'github.com' and created an organization. The source codes for various projects are found under this organization, which is private. Now, when I try to configure webhooks for these projects, I see that they deliver as intended to jenkins, but jenkins doesn't trigger the respective project's build. Instead, it gives out a message as shown below.
jenkins-github webhook error
I don't find any info regarding this webhook on global configuration page.
Here is a snapshot of jenkins logs
jenkins logs
I don't face this webhook issue for newly created pipeline-projects on jenkins. I face this issue for older pipeline-projects that already had their webhook configured earlier for gitlab.
Help me to resolve this issue and make jenkins trigger build from github webhook for older pipeline-projects.
Did you try force regenerating the webhooks?
Go to Manage Jenkins > Configure System > GitHub plugin > Advance > Re-registers hooks for all jobs.
I had this problem myself. The first thing you want to do is go to Manage Jenkins -> Configure System scroll down to the GitHub section and click on "Advanced". You will see this:
It's important to have access to your Jenkins log (I'm running Jenkins with Docker). When I clicked on Re-register hooks for all jobs, I got the following error:
In my case, the error mentioned something with my access token. So, I checked my Github personal access token and it turned out, I need to turn on Read and Write for Webhook:
Now, go back to Jenkins and click on Re-register hooks for all jobs again, and on the next push, the build was automatically triggered.
When I open a PR on GitHub, several builds are triggered on our external build server, but because of build queuing, they can run at different times.
In the interim, however, I can merge my PR after even one of the builds has successfully run.
I understand that the build server is probably using the Checks API, and that GitHub doesn't know about the check until the build server tells it that the build has started. I think this is the source of the problem because GitHub is just saying, "All the checks I know about have passed."
Is there a way to configure GitHub to expect all of my builds before the build server starts them?
My TeamCity CI has the plugin GitHub Commit Hooks provided by Jetbrains to detect new pull requests and trigger a run. I've installed this plugin and configured it clicking here:
After that, the web hook is created on GitHub but the address is 0000:8111 which is wrong. So I change to the correct DNS and redeliver the request.
It seems to work, the server returns 202 with the message Scheduled checking for changes for 2 VCS roots. (Server time: 20180615T122359.142+0100) but the trigger is not working.
After a while another problem happens, the server starts rejecting the requests and GitHub returns this:
No stored auth data (secret key) found for public key "72WE45221-19fe-433b-9265-66b2168EW6c". Seems hook created not by this TeamCity server. Reinstall hook via TeamCity UI.
Environment:
TeamCity version: 2017.2.4 (build 51228)
GitHub Commit Hooks version: 62
What I can do to solve this issue? Is there any issue with my DNS?
EDIT 1:
Now I am able to trigger the build by commits and solved the secret key issue. But pull requests are not triggering the CI.
To solve the secret key issue, you need to change the Server URL on Global Settings.
A bit of a workaround, but have you tried using a VCS trigger to detect and build pull requests rather than a commit hook? This works the same as any other VCS check in trigger, so if your current configuration is already detecting VCS changes from Github it should be more straightforward to setup.
Pull requests on Github are automatically referenced using the following pattern +:refs/pull/*/head so with a VCS branch specification you can have a TeamCity build project that's dedicated to building pull requests.
See https://blog.jetbrains.com/teamcity/2013/02/automatically-building-pull-requests-from-github-with-teamcity/
I had a similar issue; the solution is to change the TC installation's settings so it's aware of its correct URL, and then re-adding the webhook through the plugin. The setting in question is Administration > Server Administration > Global Settings > Server Url:
Currently, my team is using TeamCity to automatically build pull requests from GitHub.
We have a configuration to build all the pull requests. In the version control settings of the config, our branch specification is
+:refs/pull/*/merge
In the "Build Triggers" configuration setting, we have only one trigger with the following trigger rule:
+:root=Pull Requests on our Repository:\***/*\*
"Pull Requests on our Repository" is our VCS root name.
The issues:
When someone views a pull request on GitHub website without doing anything else, a build would be triggered in the TeamCity build agent. This is quite annoying, because from time to time, we have multiple build agents building the same pull requests (when multiple people view it).
When someone comments on a pull request, a build would also be triggered.
From my perspective, the only time I want TeamCity to start a build is when new commits are pushed to the pull requests.
Is there a way to do it?
Github's refs/pull/*/merge branches are updated every time mergeability of the branch is recalculated, i.e. on every commit to destination (most likely master) branch. They are also updated when pull request is closed and then reopened. Github's support says these branches are not intended for end users use. The only workaround at the moment is to run builds on refs/pull/*/head branches automatically and on refs/pull/*/merge branches manually.
Do you have TeamCity configured as per this blog post? I then activate the TeamCity service hook in GitHub which takes care of triggering a build in TeamCity whenever there is a push. This seems to do the right thing for me. Or am I missing something?
I know this is old but I wanted to post what we've found as alternatives:
Stop using VCS roots altogether as a mechanism for triggering pull requests. Instead, configure a GitHub webhook to notify a web app of yours whenever there is an update to a PR and only then trigger a build via the TeamCity REST API.
In your build config, add a step that checks what changed in the PR. If nothing changed (i.e. no new commits were added), or if the PR is closed, cancel the build. The problem with this is that the build queue will still be populated with builds that will then be cancelled. Also, you'd have to store somewhere the last commit that was built in order to do the check.
According to their TeamCity's issue tracker, the issue of the TeamCity.GitHub plugin causing an infinite loop of builds was fixed in v9.0