Phabricator restrict git push - phabricator

I want my team including myself to review commits of each other. None of commits should be pushed including mine into repo until it's not audited by other team member. I kind of lost in phabricator documentation, so i'm asking here, is there any way to setup that kind of workflow?

You can only restrict pushes to repositories hosted by Phabricator. If your repository is hosted elsewhere (like GitHub), Phabricator obviously can't prevent users from pushing to it.
To restrict pushes, create a new Herald rule (in the Herald application), like this:
Create a new "Commit Hook: Commit Content" rule.
Select "Global" as the rule type.
Then configure the rule like this:
When [all of] these conditions are met:
[Accepted Differential revision][does not exist]
Take these actions every time this rule matches:
[Block change with message][Review is required for all changes.]
You may want to use additional conditions like this, to run the rule only in certain repositories:
[Repository][is any of][ ... list of review-requied repositories ... ]
Or a condition like this, to let users bypass the rule by writing some string like "#bypass-review" in a message in an emergency:
[Body][does not contain][#bypass-review]
If you add a bypass like this, you can mention it in the rejection message.

It seems that you want a Pre-Commit Code Review. We set this up by doing the following (we use Git repos. If you use some other type, these steps may be different):
Setup a Herald rule
New rule for: Commit Hook: Commit Content
If you only want one repo, you can use Rule Type: Object, however, we used Global
For the conditions: we selected Accepted Differential revision and does not exist
Action: Block Change with message For the message, we refer them to an article that walks them through using Arcanist
Each project will need a .arcconfig with at least this line:
{
"phabricator.uri": "http://your.phabricator.url"
}
Day-day developers are going to have to use arcanist.
Developer creates a local branch.
Changes and commits code to the local branch.
When finished, run arc diff [base_branch_name]
This will create a Differential revision that will allow another developer to code review.
If changes are needed, the developer checks out his local branch, makes changes, makes commits, and re-runs arc diff [base_branch_name] to update the diff.
After all revisions are done, run arc land [local_branch_name] --onto [base_branch_name]
I hope this helps. Also, Phabricator developers hangout in freenode.net IRC channel called #phabricator. Come join the community; they have always been very helpful for me.

Related

Phabricator: how to fire herald rule on acceptance of of Audit?

Is there a way to create herald rule to fire once a audit has been marked as accepted?
Basically what I am trying to do is to trigger build job once a commit has been audited and marked as accepted
cheers
There is no built in functionality for reacting to commit audits. Phabricator has developed a "pre-commit" code review system that would accomplish this by putting the review process before the commit. Then, once it is reviewed it can then be "landed"/committed and then the build can kick off.
For more information on their pre-commit review, please read their "Reviews vs. Audit" doc.
There is no herald rule for accepted audits. Like CEPA already said, you need to to a pre commit review. You can create a diff without using the cli arcanist.
Do your stuff in the repo
Stage and commit changes
Create a diff for example with: git diff origin/master > diff
Create a new diff in phabricator with: Differential > Create Diff and paste the file there. If you can't find the URI just use the link https:///differential/diff/create/
Now you could create herald rules to react on new diffs and add blocking reviewers for example.
You could also protect commiting to master.
Keep in mind: This isn't the recommended way to work with differentials.

JGit plumbing API - commit new or modified file to non-current branch

Sorry, relative novice, but I have not been able to find specific example to address this. Working on a service that is using Git to store configuration documents. They would be worked on in branches until "published".
I've been able to do all the querying and fetching of documents from any branch in the local repository where the service would run, without having to "checkout" branch into working directory. I would like to do the same with a save operation.
I've found examples of using ObjectInserter, TreeFormatter and CommitBuilder to do this, but no explicit/explained example of doing this to specific branch that would produce the same results as switching, adding and committing with porcelain API.
I've played around with RefUpdate after the commit, and think I'm on the right track, but could use some help.
Thanks in advance

How do you delete Phabricator project or task

I use Phabricator for code review, but I can't delete a project once it was created. The only thing I can do is change the project status from active to archived. The other problem is Task, same to project, I can't delete a task once it was created.
Sometimes, people try to test Phabricator, maybe he or she creates some mock projects, it makes sense to delete them after testing.
It is possible, but only by using the command line administration tools.
Remove a task? ./phabricator/bin/remove destroy TASK-ID (ie: T1, T23)
Remove a project? ./phabricator/bin/remove destroy PHID-PROJ-6i6ofxwwz4xybdvg7oa5
Here is how to find the PHID: How do you find the PHID of a Phabricator object?
I've asked the Phabricator developer on IRC, user can't delete a project or task, this is designed on purpose, the only way to do it is archive project or close task. Refer to his reply as below:
We do not plan to add that feature, the feature would create a lot of problems. For example, some user could delete your stuff and you'd have no way to tell who did it. If a user closes or archives your stuff, it says "alincoln closed this task." Another problem is that a project may have thousands or millions of objects attached to it. If you delete the project, either all of those objects become attached to an empty/invalid project, or we need to run some sort of background cleanup process. And there's no way to undo deletion, so users who make mistakes can't recover from it.

fossil dvcs difference between update and checkout commands

After reading the builtin help, it seems to me that both commads can be used for modifying the workspace to match a certain revision. But I don't understand the differences between update and checkout. Please include some trivial workflows in your answer which show when update/checkout are appropriate.
First major difference is that if you have a remote url set, update will pull first latest artifacts from the remote repository.
Another difference is that if you have uncomitted changes, checkout will not run (unless you force it), whereas update will retain your changes and reapply them. With update you can therefore integrate changes from other users before committing.
So:
Update is what you need when you collaborate on a project, in order to prevent forks.
Checkout lets you deploy a particular version.

DVCS - How often and when to commit changes

There is another thread here on StackOverflow, dealing wih how often to commit changes to source control. I want to put that in the context of using a DVCS like git or mercurial.
How often and when do you commit?
Do you only commit changes when they
build correctly?
How often and when do you push your changes (or file a pull request or similar)?
How do you approac developing a complex feature / doing a complex refactoring requiring many places to be touched? Are "private commits" that won't build ok? When finished, do you push them also to the master repository or do you bundle all your changes into a single changeset before pushing?
It depends on the nature of the branch ("line of development") you are working on.
The main advantage with those DVCS (git or mercurial) is the ease you can:
branch
merge
So:
1/ How often and when do you commit?
2/ Do you only commit changes when they build correctly?
As many time as necessary on a private branch (for instance, if it compiles).
The practice to only commit if unit tests pass is a good one, but should only apply to an "official" (as in "could be published or 'pushed'") branch: in your private branch, you merge a gazillon times if you need to.
The only thing is: do some merge --interactive to reorganize your many commits on your private branch, before replaying them on your main development branch, where you can pass some tests.
3/ How often and when do you push your changes (or file a pull request or similar)?
Publication is another matter and should be done with a "clear" history (coherent merges, representing a content which compile and pass some tests).
The branch you publish should be one where the history is never rewritten, always updated.
The pace of the publications depends on the nature of the remote branch and of the population pulling that branch. For instance, if it is for another team, you could push quite often. If it is for a system-wide integration testing team, you will push a lot less often.
4/ How do you approach developing a complex feature / doing a complex refactoring requiring many places to be touched? Are "private commits" that won't build ok? When finished, do you push them also to the master repository or do you bundle all your changes into a single changeset before pushing?
See 1. and 2.: patch first in your own private branch, then reorganize your commits on an official (published) patch branch. One single commit is not always the best option if the patch involves several different "activities" (or bug fix).
I'd commit changes to my DVCS (my own topic or task branch) very, very often, this way I can use it not only for "delivering changes" but also to help me while I work: like "why this was working 5 minutes ago and it's not working anymore?" If you commit often you can just run a diff.
Also, a technique I found very, very good is using it to "self-document refactors". Let me explain: if you've to do a big refactor on a topic branch and then review the change as a whole (having modified a nice set of files), you'd probably get lost. But, suppose you checkin on every "intermediate step" and document it with a comment, then you're creating some sort of "movie" of your own changes helping to describe what you've done! Huge for reviewers.
I commit a lot; when adding functions or even reformatting my sources.
I use git and do most of my work on non-shared branches. And when I've added enough little changes that count as a block, I use git rebase to collect the smaller related changes into larger chunks and commit that to the main branches.
This way, I have all the advantages of committed code that I can go backwards or forwards in, but I don't have to commit all my mistakes, and bactracks to the main history.
How often and when do you commit?
Very frequently. It could be as much as a few times in a hour, if the changes I've made work and make up a nice patch. Or it could be every few hours, depending on whether I am spending longer debugging things, or experimenting with risky changes.
Do you only commit changes when they build correctly?
Yes, almost always. I can't think of a reason right to check in code that didn't build correctly. There's plenty of reasons you might check in code that doesn't run correctly (in a branch) though.
How often and when do you push your changes (or file a pull request or similar)?
Normally only when a feature is complete and ready for integration testing. That means it has passed unit tests and other relevant tests, and the code/patch is clean enough that I consider it ready for review.
How do you approac developing a complex feature / doing a complex refactoring requiring many places to be touched? Are "private commits" that won't build ok? When finished, do you push them also to the master repository or do you bundle all your changes into a single changeset before pushing?
I would create a named branch for the feature (which would have traceability across design docs and Issue Tracking system). Commits that don't build would only really be ok on a private branch as an intermediate step, but would still be exceptional. Currently I don't rebase and merge the entire feature branch into a single changeset, though it is something I'm looking at doing in future. Changes are only pushed when appropriate tests are all passed.
I follow this kind of flow
alt text http://img121.imageshack.us/img121/3272/versioncontrolsysbestpr.png
(Here is the original image url)
I guess this says pretty everything. Basically I would do a check-in after implementing a full working use case / user story (depends on your software process). The major important thing is that you check-in things that work in the sense that they compile. Never break the build!
Doing a commit after each user story/use case has the advantage that you have a better tracking of past versions and undoing changes is much easier.

Resources