I am using a Github plugin that allows scanning organization in Github and add the repos, branches, prs to Jenkins. It works perfectly and scans my branches and repo using webhook.
BUT! I want to add new repos to the existing view using regular expression using a Jenkins job.
Therefore I need to write it in GROOVY.
Does anyone know how I can modify in groovy the field of the behaviors?
Related
My company has few repositories hosted in GitHub with some .NET stuff, but uses ADO Pipelines for the CI/CD. Is it possible to use azurepipelines-coverage.yml (link to Microsoft documentation on it) to check pull request's code coverage? Or is that feature for ADO repositories only?
Would really appreciate any help!
I've added azurepipelines-coverage.yml to root folder along with main pipeline (new simple repo with simple code, few tests and repo), however, not sure how to "use" it, as there's no option to add it to PR check (similarly to ADO repos branch security).
I'd like to make a new git branch, add a commit, and then push to github. In addition, it would be great to create a PR for that branch straight from Jenkins job.
Has anyone done it yet? The part I'm struggling is how to create a PR. For creating a branch and commit, I'm running regular git commands in the shell.
Thanks, N.
Sounds like you want the pipeline multi branch plugin there's a blog here https://jenkins.io/blog/2015/12/03/pipeline-as-code-with-multibranch-workflows-in-jenkins/ that might help too. We use this plugin on the fabric8 project and it works great.
Correction: I misread the question initially. We use a shared pipeline library that contains reusable functions to make pull requests. This is an example where we make version update PRs on downstream repos once a release has finished. The groovy code that interacts with the github api is here
I am using Github as my repo as well as my Kanban/Scrum board. We use Visual Studio Team Services for our automated builds. We really like the way VSTS works and it works well with Github as the repo.
However, I want to be able to create a new Github issue/bug if and when our Continuous Integration build fails. I know you can create a VSTS Work Item but I would rather keep all issues centralized.
Is there any way to hook up VSTS to create a Github repo whenever a build fails? Or perhaps create a Github issue whenever a new VSTS Work Item is created?
We are running our own build server so possibly something can be done on that end?
Yes, you can create a github issue when VSTS build failed with two options.
Option1:
In VSTS build definition, add a powershell task in the end of the build process. Functions in the powershell should include:
Detect above build tasks in the build definition. Use REST API timeline to get build detail, you can find each task result in result parameter.
Determine to create a github issue or not. If all above build tasks are pass to build, don’t create github issue. Else, create a github issue by github API.
Option2:
Create your own website, and in VSTS use web hooks to tigger build fail information for your own website. After your own website receive the build information, it can create a github issue.
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 a CI build that is setup in TeamCity that will trigger when a pull request is made in BitBucket (git). It currently builds against the source branch of the pull request but it would be more meaningful if it could build the merged pull request.
My research has left me with the following possible solutions:
Script run as part of build - rather not do it this way if possible
Server/agent plugin - not found enough documentation to figure out if this is possible
Has anyone done this before in TeamCity or have suggestions on how I can achieve it?
Update: (based on John Hoerr answer)
Alternate solution - forget about TeamCity doing the merge, use BitBucket web hooks to create a merged branch like github does and follow John Hoerr's answer.
Add a Branch Specification refs/pull-requests/*/merge to the project's VCS Root. This will cause TeamCity to monitor merged output of pull requests for the default branch.
It sounds to me like the functionality you're looking for is provided via the 'Remote Run' feature of TeamCity. This is basically a personal build with the merged sources and the target merge branch.
https://confluence.jetbrains.com/display/TCD8/Branch+Remote+Run+Trigger
"These branches are regular version control branches and TeamCity does not manage them (i.e. if you no longer need the branch you would need to delete the branch using regular version control means).
By default TeamCity triggers a personal build for the user detected in the last commit of the branch. You might also specify TeamCity user in the name of the branch. To do that use a placeholder TEAMCITY_USERNAME in the pattern and your TeamCity username in the name of the branch, for example pattern remote-run/TEAMCITY_USERNAME/* will match a branch remote-run/joe/my_feature and start a personal build for the TeamCity user joe (if such user exists)."
Then setup a custom "Pull Request Created" Webhook in Bitbucket.
https://confluence.atlassian.com/display/BITBUCKET/Tutorial%3A+Create+and+Trigger+a+Webhook
So for your particular use case with BitBucket integration, you could utilize the WebHook you create, and then have a shell / bash script (depending on your TeamCity Server OS) that runs the remote run git commands automatically, which will in turn automatically trigger the TeamCity Remote Run CI build on your server. You'll then be able to go to the TeamCity UI, +HEAD:remote-run/my_feature branch, and view the Remote Run results on a per-feature basis, and be confident in the build results of the code you merge to your main line of code.
Seems that BitBucket/Stash creates branches for pull requests under:
refs/pull-requests//from
You should be able to setup a remote run for that location, either by the Teamcity run-from-branch feature, or by a http post receive hook in BitBucket/Stash.
You can also use this plugin : https://github.com/ArcBees/teamcity-plugins/wiki/Configuring-Bitbucket-Pull-Requests-Plugin
(Full disclosure : I'm the main contributor :P, and I use it every day)