I am looking for a possible solution not to let a PR merge if there is a force push to the source branch.
Is it possible to disable force push to a specific branch type(say feature/) once a PR is raised with the same branch as the source or target?
Or the other way around, is it possible for PR not to accept changes based on force pushed?
As force push to PRs remove review history and makes hard to track and review. It would be nice to have one of the above options workings
Related
Please read carefully as I believe my use case is unique and I have tried searching a lot on how to do this, but I am still unsure.
Generally, I am trying to set up a repo for a group of developers to work on and have it contain CI checks and require reviewers. However, I have run into some issues with how Github enforces branch protection. On top of that, I cannot use Actions as we are using a self-hosted Enterprise Github through an organization.
My desires:
Use Jenkins (which is already set up and building) builds as checks for PRs. If the checks don't pass, you cannot click merge on the PR.
Allow pushing to a branch that I have a PR up for so the author can push changes based on PR comments.
Require two approvals from maintainers. You cannot click merge without these.
It seems I could protect a master branch for example. However, I would like to enforce the PR checks whenever a person chooses to make a PR. For example, from one dev branch into another dev branch.
Use case:
An author sets up a PR for merging a branch some-work into dev. Jenkins builds the HEAD of the branch some-work to evaluate the checks. I would like to enforce this PR to have two approvals from maintainers. So, those reviewers make some comments and request some changes. The author makes those changes and pushes a new commit to the some-work branch. Jenkins runs on the new HEAD to reevaluate the checks. Then, if-and-only-if the two reviewers approve and the checks pass can the merge button be clicked.
What I have tried:
Using Github branch protections: the required approvals and the required status checks. However, this prevents any pushing or force pushing to the branch being developed on. I could just apply these protections to master, but I also want these checks part of any PR (even dev2->dev1, for example).
Github actions, but these are not available in the self-hosted enterprise Github I have to use.
What I understand:
I understand that I can protect master, for example, in this manner with the native Github branch protection. However, if I want master to be something that always works, it is understandable that developers would break up a feature into multiple branches. They would also want their follow developers to review it when merging it from their branch to an intermediate (non-master) branch. Then the actual branch being merged into master consists of code written by many developers.
Thank you all in advance for your time and help. :)
Using Github branch protections: the required approvals and the required status checks.
However, this prevents any pushing or force pushing to the branch being developed on
But... that issue (not being able to push a protected branch) could be part of a possible solution.
I would make jenkins create/reset a PR branch based on a push on a topic branch (like some-work-pr, based on some-work)
some-work is not protected, and can receive commits at any time
some-work-pr is created by Jenkins protected, and cannot be modified: compilation/test/review/approval happens here.
PR would only be done from xxx-pr branches (protected PR branches created/managed by Jenkins), while other topic branches continue to evolve.
You can only enforce these policies with branch protections, so if you want to enable required CI checks before merging a PR for all branches, then you need to protect all branches (e.g., with the pattern **). In that case, you'll need to have developers use a forking model for your repositories so that they can push code to their forks and then merge in the changes via pull requests only.
Note that if you adopt an approach where projects are implemented as a set of small, incremental changes that are merged frequently and use feature flags to control whether the code is enabled, then as a practical matter developers will only merge into the main branch and you can get away with only protecting the main branch.
I want to create a TFS policy that blocks a changeset from being checked in if a certain keyword is found in the diff.
This will allow me to make local changes for testing ideas without worrying that these changes will be mistakanly checked in, as long as I add something like //nocommit in the code.
How can this be done?
There is no out-of-box check-in policy to achieve your requirement, you have to customize your own check-in policy and use command tf diff itemspec /noprompt to compare files.
As a suggestion, you could consider using Git version control, create a branch from master and work on the branch. When you are ready to merge your code to master, create a pull request to review the code. In order to protect master, you could set branch policy on master. After you set up a branch policy, you cannot directly push changes to the branch. Changes to the branch are only made through pull requests.
When using Gerrit Code Review - is it possible to checkout all unreviewed changes for the master branch in one go? I know it is possible to checkout a specific patch set (https://gerrit-documentation.storage.googleapis.com/Documentation/2.12.2/intro-quick.html#_trying_out_the_change), but I would like to get all pending-review commits for the master branch.
Background: we currently aren't using Gerrit yet but we are going to. We have both automated and manual testing of the master branch and I would like to be able to keep on using that, before the review step, so I need to be able to checkout a branch with all pending-review commits.
AFAIK, Gerrit does not provide that feature. In fact, I am not sure if that is even possible without human interaction. If there are N independent unreviewed commits to master, there could be conflicts between them that would make it impossible to automatically build up a branch made of all N commits on top of master.
Is it possible to do pull request in bitbucket style in Phabricator?
Eg. to branch off of some existing branch and then to create pull (merge) request to merge new branch back?
I see that Phabricator differential tool only allows to submit some manually entered diff to some branch. Is it the only way?
You can mix git and arc together, but it does go against how arc diff is meant to be used.
You could leverage audit instead, although I haven't gone into any details about that below (nor have I used audit, yet).
Below, I've tried to explain our new workflow, coming from git-flow to an adapted version using git and arc diff.
Background
Before we started using Phabricator we used Gitlab and created merge requests. These would get reviewed by another developer. We use JIRA and our workflow incorporates a review required stage which has several checks before progressing into testing.
At this point, we've pushed the branch to the remote, requested a review and awaiting testing to occur (we have a mix of both manual and automated testing).
Once the review has been accepted and tests have passed, the feature branch is merged into origin/develop.
New workflow
Our new workflow removes the need to create the merge request within Gitlab, especially for reviewing.
My team still uses a workflow that incorporates git-flow, however, we've introduced the arc diff command. This creates the diff within Phabricator. The developer pushes his branch to the remote, but doesn't raise a merge request.
We run the following commands when creating a diff (merge into origin/develop)
git checkout -b feature/foo
git add <files>
git commit -m "A useful commit message"
git push origin feature/foo
arc diff origin/develop # this creates the diff within diffusion
Once the review has been accepted, we don't merge (or arc land) the branch, we await all testing to take place. This allows us to update the diff should testing fail and the developer who reviews can easily see which commits need reviewing.
Once testing has passed we can simply merge, either using gitlab merge request or the command line. We usually run arc close-revision <revision-id> to close the revision within Phabricator itself.
Additional notes
I believe the philosophy of arc diff is that you don't push your local branch. Instead you create a diff which diffusion displays. This is classed as a pre-push workflow.
Phabricator also has a post-push workflow which incorporates audit. You can simply mark commits ready for audit by amending your commit messages.
No, see https://secure.phabricator.com/T5000 to track this feature request.
Differential's primary input should be Arcanist, the Phabricator command line tool. It wraps git and provides lint, unit, and other precommit checks that help reduce time spent reviewing code. For example, it can emit patches and amend code before submission for review.
https://secure.phabricator.com/book/phabricator/article/arcanist/
When I use Egit to push something to a team in Bitbucket (we are all admins), the previous post from any member is deleted. The same thing happens with the other members if they push something too.
I use this configurations:
Everything works well but this, there's any idea to solve this?
Why do you have "Force Update" checked?
Normally (when "Force Update" is not configured), in a situation where you would discard other people's changes, the server rejects the push with a "Non fast-forward" message. In that case you have to first merge the remote changes into your local branch, and then push again. With this, the other changes are preserved.
But when you have "Force Update" checked and push a branch, what happens is that the branch on the remote repository is updated to point to the same commit that it pointed to on your local branch. That happens even when your branch is behind or has diverged from the remote branch, causing it to effectively overwrite/discard the other people's commits.
So what you want is to disable "Force Update" for refs/heads/* (head is another word for branch). See also Note about fast-forwards in the help for git push.
As a note: In some server software it's possible to configure the repository so that such "non fast-forward pushes" are denied (regardless of the force flag of the client). But that doesn't seem to be supported by Bitbucket yet, see this issue.