I am looking for a way to avoid other dev to merge my pull request before it's ready in CodeCommit, similar to marking a Pull request as a Draft: in GitLab so that it can not be merged unless the Draft: or WIP: keyword is erase from the title (see this GitLab feature)?
Is this even possible in CodeCommit or do I have to edit my Approval rule? If yes, how?
Thank you in advance for your help, have a good day!
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 context is as follows: -
I configure my GitHub CI workflow file (the YAML file) such that the workflow runs only when there are changes to certain directories:
name: testing
on:
pull_request:
branches:
- develop
paths:
- 'dir_1/**'
- '!dir_1/README.md'
- 'dir_2/**'
- '!dir_2/README.md'
I have set a branch protection rule on the develop branch that makes a merge into it possible only when the status checks are successful.
Now when I create a branch based off of the develop branch, make some changes to dir_3 (please note it is different from dir_1 and dir_2 mentioned in the YAML file code snippet), push that branch and create a pull request, GitHub expects status checks to be completed and merging is blocked till the time they are, as follows:
When I check the Actions tab, I find no action running.
So the merging is blocked indefinitely. I think that's because the branch protection rule and the YAML file code snippet contradict each other (the branch protection rule is waiting for the status check to be completed but due to the restriction in the YAML file, no status check is run). I have the following questions: -
Is my reasoning correct?
If yes, is there a way to protect certain subdirectories of a branch instead of the whole branch on GitHub? I want to allow merging if the 'protected subdirectories' are unchanged.
If the answer to 1 is yes and 2 is no, is there some other way to allow merging if the subdirectories not specified in the YAML file are changed (while retaining the branch protection rule)?
Thank you for taking the time to read the question.
On Googling the question, I found this result but it wasn't very helpful.
One of my office colleagues suggested an alternate solution to the above problem. Using paths-filter action instead of using the paths or paths-ignore key as mentioned in the Github Actions documentation solves the problem. So if the changed path is not supposed to trigger a step in a workflow, the step will be shown as skipped while running the tests and GitHub will not wait indefinitely for the tests to finish running (i.e. it will show that the pull request can be accepted).
This problem is also described in this comment of the issue. My colleague has posted the solution as a comment in the same issue. You can refer to it to see how the paths-filter action can be used to solve the above issue.
If someone has a better solution to solve this problem, please do post it. For now, I am marking this as the accepted solution. Thank you.
I'm trying to find a way to restrict a PR creation from something starting with feature/xxxx to release/xxxxx ( or in a simpler way, from feature branch to release branch) in Azure DevOps. A workaround might be filtering the path in build validation of branch policy as mentioned here, but it needs a build pipeline for this. Is there any other way that this can be done? I know about these two predefined variables in Azure DevOps: System.PullRequest.TargetBranch, System.PullRequest.SourceBranch but then again these are only available for yaml pipeline. I'm pretty new with this. Can anyone help?
Unfortunately, there is no permission to restrict PRs. The only way is set branch policies to protect target branch. You can use the workaround you mentioned, or you could add required reviewer for the affected path:
I wanted to know how I can build a Jenkins job right after merging a pull request into the master branch.
I'm very new in this Jenkins/Github thing and wanted to know how/if it's possible to achieve this without using webhooks.
Best Regards
Luca
You need to create a CI file. Basically it's a file that tells Jenkins what it can do, how to do it and when to do it. You then create a build job that should be run on master branch and set its firing hook as automatic . That's a tl;dr version that sketches how it's done in general. For specifics you have to check a manual.
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.