I would like to use MyGet build service to build my project hosted at GitHub. However, the service is triggered unnecessarily by updating README.md or other documents in the repository. Is there any way to skip these kinds of commits?
Unfortunately, there's no way out-of-the-box to filter commits, as there's no way for a machine to know what you'd like to build and what not (without going through extensive configuration). The GitHub commit webhook will fire either way, no matter what you commit. Any service responding to the webhook will listen for the event, including MyGet.
However, you could build your own triggers as MyGet Build Services supports POST web hooks. You could add your own filtering to your custom trigger, and choose when to fire the webhook, and when not to.
Details about how to create a custom build trigger for MyGet Build Services can be found here: http://docs.myget.org/docs/how-to/auto-trigger-a-myget-build-using-an-http-post-hook-url
Related
We have a business need to manually approve every (external) upstream change before we start using it and only allow our developers to use an approved whitelist of packages and versions.
The two ways I can see to do this are either:
disable all pipelines and halt all development, enable an upstream source and pull the new package through and then disable it; making sure no additional upstream packages were pulled while the source was enabled
not use upstream sources but instead republish all packages manually (ongoing work will not be impacted while package approvals occur)
I have some basic tooling created to manage the manual approval and republish pipeline (I currently do this with a network local nuget registry and npm registry) so #2 seems like the path for me to take, but if I could simply upload a list of approved packages instead I could maybe simplify my workflow.
Is it possible to whitelist upstream packages in azure devops without disabling upstream sources?
Sorry for any inconvenience.
I am afraid there is no such way to whitelist upstream packages without disabling upstream sources at this moment.
Just as you know, there is not much settings for upstream sources currently, just add/delete, enable/disable. We could not have any way to set a whitelist to filter the packets from the upstream source.
As you have a business need to manually approve every (external) upstream change, you could add your request for this feature on our UserVoice site (https://developercommunity.visualstudio.com/content/idea/post.html?space=21 ), which is our main forum for product suggestions. Thank you for helping us build a better Azure DevOps.
Besides, as workaround, I also agree with the second way. We could use file matching patterns to publish multiple packages:
Push NuGet packages
Hope this helps.
How do you get VSTS to build when a PR is created in GitHub? I've tried several triggers in the VSTS build like refs/pull/*/merge and refs/pull/*/head. I have a build working when a commit is made to the master branch, but I can't get a build to trigger when a PR is created.
I get the following when a PR is created.
Also, the webhook history shows that a message was successfully posted to VSTS, but the build never starts.
The official Microsoft VSTS GitHub Integration extension now supports this directly.
I think it's the trigger. Try what's described in this blog post.
There is not an easy way to enable this today for PRs. It is on the VSTS feature backlog that we want to address soon.
The way to make it work today would be to do something like: add a webhook to call your own custom service endpoint. Within your service endpoint, you could then call into VSTS to queue a build, and the build would need a step to post success/fail back to GitHub.
In your custom service endpoint, you would need to make sure the user is authorized as a contributor on the GitHub repo.
On the new VSTS UI you can find it in Build Edit -> Triggers:
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:
Say I have a project, that depends on and build with the latest commit from a repository, managed by someone else, is there a generic way to get build triggering? I am not talking about for a project that you own where you have access to the Webhooks settings but where the project is someone else's.
An example I have for this is Docker images. Where I dockerise an application, I want to have a CI system rebuild that image whenever the application's source repository is updated. I don't have control over the webhooks of the application vendor's git so cannot add a webhook, but would like a trigger when it is updated. A short delay is reasonable (it does not need to be instant).
For argument's sake, we can assume that the repo is hosted on GitHub and that the CI supports web hooks.
Is there a tool/service that does this? I don't think that there is a way provided by GitHub or any of the other large Git hosts (GitLab or BitBucket) for doing this, but if I am mistaken please let me know. All I can think is to poll the repo in some schedules job and trigger the build from that. I suspect there may be a plugin for Jenkins to do this but would like something generic and if polling can be avoided in favour of the publish/subscribe model that would be perfect.
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