Is it possible to merge pull request automaticaly to master branch on github after success of travis test webhook?
You can use Mergify to do this.
It allows to configure rules and define criteria for your pull request to be automatically merged. In your case, setting something like "Travis check is OK and one reviewer approved the PR" would allow the PR to be automatically merged.
(Disclosure: I'm part of the Mergify team.)
You can most probably add an after_success action to your .travis.yml that would merge the PR using GitHub API. I do not know of any ready to use script for this, but there is no reason for it to be hard. Special care needed for authentication ...
GitHub recently shipped this auto-merge feature in beta. To use this, you can enable it in the repo settings. Just keep in mind you will need to add branch protection rules as well.
See the documentation for more info.
https://docs.github.com/en/free-pro-team#latest/github/collaborating-with-issues-and-pull-requests/automatically-merging-a-pull-request
I work on a project that requires pull requests to be up to date with the target branch, and also to have passed all the checks before merging.
This means we can often be waiting for checks to finish, only to find a new commit has been made to the target branch, which requires the pull request to be synchronised and the checks to run all over again. I wanted a simple app to merge the PR automatically once the checks are successful, so I created one.
Mergery is:
Free, including for private repositories.
Fast. It's event-driven, it doesn't run on a schedule.
Simple. No configuration required. Just label your PRs with automerge.
Related
To keep it short, I'm using a script in Azure DevOps that generates a pull request automatically every time a new branch is pushed to the repository.
Said script enables the pull request "auto-complete" funcionality, which lets me merge code using GIT after I complete all the branch policies. I have only one branch policy enabled, which compiles my code and checks whether it should complete the pull request or not, based on the pipeline compilation results.
Everything was working fine before one week ago, people pushed their branches normally and ADO automatically created the PR, build checked, merged and auto-completed the PR, as my only branch policy had always been met.
Now even all branch policies are met, the PR is stuck and won't auto-complete for some reason, even after the build compilation turns out as success and there are no merge conflicts.
If I click on approve, it then begins to complete automatically as it should. However, this manual step was never necessary for the PR to finish, nor I have a branch policy that demands an approval to complete the PR.
This is affecting all the projects in my ADO organization, so it may not be a configuration problem.
Maybe anyone has stumbled across the same problem?
Edit: Microsoft is looking at the issue: https://developercommunity.visualstudio.com/t/Pull-Request-doesnt-automatically-compl/10082816
Based on the link provided in the question, this issue apepears to have been fixed on Jul 28, 2022
"Microsoft Solution - Feedback Bot
Closed - Fixed
We have released a fix for this issue! Thank you for providing valuable feedback to help improve the product."
You could check if the user account has the permission: Bypass policies when completing pull requests.
The scope of tis question is GitHub repositories.
Is there an easy option to enforce a few code quality rules before a commit can be done?
I have linting tools that I can run in a GitHub action runner. I hope I can run the linting scripts and prevent the commit if the lint program has an error output.
I think I am missing a pattern or special GitHub feature here. A link to documentation would be a great help.
If you're using github.com (that is, not a GitHub Enterprise Server instance), then you cannot run hooks on the server side. That's because hooks execute arbitrary code, which is of course a security concern.
The easiest way to do this is to run a CI job, such as you have in the GitHub Actions runner. You'd create the workflow file that runs the linting tools, such that the linting tool or your check script exits nonzero if the commit should be rejected. You can see the workflow file for Git LFS that runs script/cibuild to perform this kind of check.
Once you have your CI job working as you expect, you can protect the branch by going into the repository settings. Choose Branches → Branch Protection Rules, and create a check for whatever branch you want to require checks for. Usually this is your default branch. Choose “Require status checks to pass before merging” and then enable the relevant checks to make them required.
From that point on, in order to merge code into the protected branch, the checks must pass. If you want to require this for all branches in the repository, then you can use a wildcard, but you'll need to use a forking model since this will prevent people from pushing branches into the repository.
Note that this is much better than trying to use a pre-commit hook on the user system. As the Git FAQ explains, pre-commit hooks are easily bypassed, so while you can provide them for developers who want to use them, you can't require them. pre-commit hooks are also an impediment to certain workflows, so advanced developers may not care for them.
I'm using a build policy on one of my Azure DevOps git branches.
Is there any way of requiring a manually triggered branch build policy be run again if the source branch is updated?
My branch policy is set to Manual trigger. We use Manual instead of Automatic to reduce the number of builds (we use self hosted build server) running on our CI server as we typically open PR's early to provide feedback and facilitate conversation around code.
If the trigger was set to automatic, then any time source branch is updated a new build is queued. This isn't case with Manual. I had situation where build policy passed but then a further commit was made to branch and the reviewer approved. But the build was not manually triggered again and the last commit & push introduced a bug. I'd like the build validation policy to either reset or fail every time the source branch is updated similar to how code reviewer votes are reset after a push.
Is this possible?
I do not think this is currently possible, it has been raised on the Developer community as a feature request / issue, so I would encourage you to up-vote this here.
A solution for our scenario (too many builds were being queued, because Code Reviews come back with changes) was to use Pull Request drafts.
Sprint 143 - Draft Pull Request
When creating a PR, you can click Create as Draft in the drop down beside the Create button.
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:
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