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?
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.
There is an open source project (https://github.com/firebase/firebase-jobdispatcher-android), which I would like to get built using travis/circleci or another cloud ci. However, those CI's don't allow you to get to repos that are not yours.
I didn't try, but I have a hunch that I won't be able to get a webhook setup as well to get notified when those repos 'master' branch is updated.
Why not fork ? Because then I somehow need to manually\use cron server to get my forked repo updated! It loses the point of having open source repo builds...
Why do I want to build it continually? Because they do not upload their .aar output to mavencetral or jcenter and I don't want to put the .aars in my project and get it updated all the time - bloats the repo...
In any case, I don't get it - there's an open source project, the repo exists and open to everyone, pulling the data and getting webhooks doesn't compromise that repo in any way why isn't this possible ????
If I'm mistaken and web hook is possible, how can I set up a build that will end up in uploading to mavencentral (probably gradle plugin, I have an account and be happy to have a public copy there)?
(I thought of micro service, free of course of some kind + docker based ci which I can pull and build whatever, I don't mind if a build will take time).
So, I've been using Jenkins for quite a while. I have set up numerous projects with the Github Pull Request Builder plugin to run tests whenever someone opens a pull request, and then trigger some other job (build, push, deploy, etc) whenever the pull request actually gets merged to master.
So, is there any way to set this up with a Jenkinsfile, or the organization folders, or the multibranch build deal?
The github-organization-folder plugin in combination with the multi-branch plugin plugin offers exactly this awesome feature: It scans a whole organization (optionally restricted to certain patterns in repo/branch names) for Jenkinsfiles and automatically adds jobs. This also happens for Pull Requests.
Once the PR is closed, it automatically removes the job.
To avoid arbitrary code execution, an organization member has to trigger building the job (same as for the GPRB plugin). The phrase can be configured in the Jenkins System settings.
EDIT: Under the Advanced section in Jenkins, you find options about what types of PR you want to build. If you build fork PRs, then there's afaik no way to prevent running code without prior inspecting it.
An example, how this looks like:
I have created a build configuration in TeamCity (v8.0.1) to automatically build my Github pull requests by setting my VCS branch specification to +:refs/pull/(*/merge) (I followed this blog post).
TeamCity is picking up new pull requests and changes to existing pull requests just fine, however it is kicking off multiple builds per change when I would expect it to only perform a single build.
For example, I pushed up two commits to an existing pull request which resulted in 8 builds being executed by TeamCity. When I look at the changes for each of the builds the change graph is identical except for the commit hash of the pull request's build (at least I think that is what it is), e.g.
I have confirmed that Per-checkin Triggering is disabled in the Build Trigger configuration. I have also confirmed that we are not using any of Github's TeamCity hooks.
Any ideas what the problem might be?
I'm not sure what could cause this, but have you tried to turn on "Quiet Period"
http://confluence.jetbrains.com/display/TCD8/Configuring+VCS+Triggers
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