Recently, I've met several bots in Google TensorFlow git repos.
When I submit a PR, one TF bot finds some related groups for the PR and says, "Can one of admins verify this patch?"
Then, one of a verifier bot says, I need to signup something, and I left a comment, Done. Then, the bot checked and marked it was done.
Then, later one admin commented, "jenkins, test please." I guess this triggers Jenkins and reports the test and other checker results.
How could I setup the (bot)environment and github workflow like this?
https://github.com/tensorflow/tensorflow/pull/1838
You have to learn a continuous integration tool like jenkins. Jenkins has triggers to find such events. After events like below triggered. You can use variety of plugins to accomplish very different tasks.
Source Code commit
Source Code push
Poll bug tracker periodically.
For example
Jenkins twitter plugin
Jenkins github plugin
There are a lot of different plugins for jenkins. See them here.
They use this plugin in jenkins :
https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin
All how to configure is given on the page
Related
looking for workflow solution. We need something like ad-hoc sharing workflow https://docs.bit.dev/docs/workflows/projects with one addition - before the component publishing could happen only after the code review. let me try to describe the short scenario:
there is a repo with the shared components
there are several consumer projects. each one sits in its own repo
there is no dedicated team to maintain the repo with the shared components
the developer of consumer project imports a share component and make changes
the developer wants to create a pull request for a component changes
So far I see only one solution - the developer manually applies changes he made locally to a shared library repo and manually creates a pull request. Kind of boring. Does the bit.dev provide an automated solution for such case?
While a PR-like feature is still not available in Bit, you can use Git's PR workflow to set up a code review process for components with some automation.
Note this flow can work regardless of the specific workflow your team implements. In this answer, I'll focus on the ad-hock flow, as your team uses.
You'll first need to set up automation on your projects, that when there's a change in component's code, your CI will bit tag && bit export the modified components. This should happen only when a PR is approved and merged to master branch (in Git).
Then using the Git integration feature set up your projects to receive PRs on new versions for components.
With these two setups, this will be the workflow your team can utilize:
Import component to any project and modify.
Submit PR to the project.
Have a peer do a code review.
When change is merged, run bit tag && bit export --eject during CI
Commit and push back changes to package.json to the repo (with a skip-ci flag, per your automation infrastructure).
All projects that use that component get a PR from Bit with the newly available version.
I will update this answer whenever a new feature in Bit improves on this workflow.
as Itay says, you can use the GitHub integration on bit.dev.
But if you want, I create demos projects that show how to use GitHub or Azure CI to integrate the project with Bit, and export new components when code our pushed to master, and also run Bit script on PRs.
https://github.com/teambit/bit-with-github-actions
https://github.com/teambit/bit-with-azure-devops
I hope it will help you.
I configured SonarQube analysis to report it's status to pull requests on my GitHub project. SonarCloud already supports pull requests as first class citizen as described in https://blog.sonarsource.com/sonarcloud-loves-your-build-pipeline. As I understand, this kind of integration is not using the GitHub Plugin for SonarQube.
The configuration provides these properties (look here for the complete configuration)
sonar.pullrequest.provider
sonar.pullrequest.github.repository
sonar.pullrequest.branch
sonar.pullrequest.key
The credentials for the technical user are set in the SonarCloud project administration.
You can see the results here: https://github.com/BudgetFreak/BudgetFreak/pull/86#pullrequestreview-125364230
Every issue is reported as an inline comment, one summary comment is made and the status is reported for the code-quality/sonarqube check.
I would like to disable the inline comment on every issue. This was possible using the GitHub plugin. Can this also be achieved with the new pull request integration?
Unfortunately, on SonarCloud, this feature is not available.
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 followed this answer to set up a Jenkins job, and it's working fine.
I have scheduled a Job on github master commit push as
Poll SCM : * * * * *
But, it continuously starts a build Job each minute.
How can I restrict this so that it runs only once per commit push?
There are several options. The two I've used with most success are:
Use a git commit hook to call the Jenkins rest API to start the job. The simple approach is to call the job's build API call directly (something like http://jenkinsmachine:8080/job/your-jobs-name/build), but that hardcodes the job name and branch into the git hook script. A more flexible approach is to use the Git plugin's own rest mini-API, as described by Kohsuke in his blog.
Use something like the Throttle Concurrent Builds plugin or a creative use of slaves nodes and executors to limit the number of cuncurrent builds of that job.
The first option is much preferred, but there are times when rest access to the jenkins machine from the git machine is not available, so the second option can be used in those circumstances.
This approach is actually polling. That means Jenkins is scanning every minute if there aren't any changes in GitHub repository.
If you want true Push from Github to your Jenkins You need to Integrate Github WebHooks with Jenkins. I wrote a blog post on this subject. Scroll to section 2: "Jenkins - Github Integration"
If you are just playing around or using it for your personal open source project, you may want to look into Jenkins alternatives like Drone.io or Codeship.io. These services are generally free for open source and can configure Github Webhooks in few clicks. But they are not suitable for complicated enterprise builds.
I have an organization on GitHub with private repositories. I also have Jenkins set up running on port 8080 on a server, with the GitHub plugin installed. I've created an account on GitHub for my jenkins user, which resides in the owners group.
I'm trying to trigger a job on jenkins when a change is pushed to my development branch (or master branch, neither seem to be working).
When I look at the GitHub Hook Logs in Jenkins, it says that Polling has not run yet. When I go to "Manage Jenkins", the GitHub plugin says my account is Verified when I test it.
Any insight on how to configure this? I have multiple repositories I'd like to work with, so deploy keys don't seem like the solution to me.
Update:
As Craig Ringer mentions in his answer, you can select Grant READ permissions for /github-webhook in "Configure Jenkins" under the GitHub plugin settings, allowing the webhook to be called without authentication.
Another update: Webhooks are now (Dec. 2014) available for organization: see WebHooks API for orgs.
Note: the issue 4 of the hudson-github-plugin was about:
Last GitHub Push
Polling has not run yet.
And the conclusion was:
Nevermind, the only missing piece was a permission checkbox for the github user which ain't documented anywhere on the internet.
So is this a permission issue regarding your Jenkins users?
The article "Set up Jenkins-CI on Ubuntu for painless Rails3 app CI testing" includes the following process:
To restrict the CI system and give access to your Team members to use or see the build logs, first you’ve to create an account.
Go to Manage Jenkins > Configure System,
Check the Enable Security checkbox
Under Security Realm, choose Jenkins's own user database
Check the Allow users to sign up checkbox
Under Authorization, choose Project-based Matrix Authorization Strategy
Add first user with the name admin and another with GitHub (Note: the username for Admin access has to be admin) For GitHub named user, just choose the Overall Read only permission. We’ll use this user later with the GitHub hook.
Note: The admin and GitHub user that we’ve added in the above step does not create the User. Then you’ve to create a real user with that same name. Ya, I know, its a bit weird with Jenkins UI.
Go to Manage Jenkins > Manage Users > Create User. Create both admin and GitHub users.
Hooking with the Github web-hooks
Now to run the build automagically when new commit or branch gets pushed onto Github, we have to setup the repository.
Got to the hooks page for your repository. e.g.
github.com/<username>/<project_name>/admin/hooks
Under AVAILABLE SERVICE HOOKS > Post-Receive URLs, add github:github#your-ci-server.com/github-webhook/.
The github:github is the user that we’d created earlier.
Then we have to verify Jenkins with Github. Go to Manage Jenkins > Configure System and under GitHub Web Hook, add your Github username and password and click the Test Credential button to authorize once with Github.
It looks like the accepted answer is no longer necessary with the current version of the GitHub plugin. You can instead check Grant READ permissions for /github-webhook in "Configure Jenkins" under the GitHub plugin settings, allowing the webhook to be called without authentication.
As explained in the help on this option that's quite safe, and frankly no worse than having a user named "github" with password "github" anyway.
There are two ways to achieve automatic builds on Jenkins. What you choose depends on whether GitHub can call the Jenkins server URL you provide. This may not be the case if you are running Jenkins behind a firewall.
If GitHub can reach that URL you can set up the service hook on your repo there.
If not you can set up Jenkins to poll periodically.
You may set up both, but one solution is enough to get it working. I would always go for the first if feasible as it saves resources CPU and traffic wise.
Either way you need the GitHub plugin for Jenkins.
Hope that helps a bit.