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.
Related
we are using Phabricator to performs pre-commit reviews & audits on a mercurial repo. Phabricator does not host the repo, it only observes it.
The project was configured with auto-close, so until recently, pushing all commits of a validated review on the repository automatically closed the related revision.
So far so good.
Today, our admin found out that a php lib was missing and installed it. It seems the deamon never work 'correctly' until now. However, from this moment, all existing reviews have been updated in a way that the very first commit of the review is the only one that can be seen. Any new review is fine until it is closed, where Phabricator writes:
Closed by commit R1:a9a9e1153022: doc: update changelog (authored by vsiles). ยท Explain WhyThu, Sep 7, 5:09 PM
This revision was automatically updated to reflect the committed changes.
(were a9a9e1153022 is the revision of the very first commit, but that's was always the case iirc). Now the whole review only shows the first commit, not all of them.
If we go to the 'History' tab in the review, we can see that Phabricator added an additional 'Diff' with the revision & timestamp of the first commit, after all the diff we pushed. This seems to be the problem. If we modify the history to show all commits but this one, we find back all our review content.
For the moment, my only work-around is to remove the 'auto-close' feature, and close reviews by hand using arc close-revision DXX. There is no more automatic step by Phabricator that messes things up, and the additional diff is not generated by Phabricator.
Can someone explains why Phabricator considers that the review is closed by the first commit, which seems to be the issue here ?
The recommended workflow for Phabricator is to use arc land to push and close the revision. Pushing using mercurial directly may not have the desired outcome because mercurial has no knowledge of Differential revisions, and Phabricator daemons are left to try to reconstruct what they can of the links between revisions and commits after the fact.
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
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.
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.
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.