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.
Related
I've noticed I can edit a Phabricator diff's summary field directly from the web app without having to update the git commit and then updating the diff, but it's not clear to me which changes take precedence. If I Edit Revision via the web app and later land the diff, will those changes get overwritten by the latest git commit message?
You can run arc amend to update the commit message locally based on what phabricator has recorded in differential. I think this is also ran before landing so it should update your local commit message if you change things in the web UI. I don't think the same is true in reverse, however. If you later update the commit message locally after submitting to differential, arc amend will overwrite your changes with the message from differential.
How can I find out which tickets were closed between one build and the previous stable build? I'm trying to design a new build process, so I'm not set on particular tools yet. Which ones would let me see this sort of info in a dashboard, if any? Should I try to do this from a bug tracker, or from a build pipeline such as Jenkins or Bamboo, or somewhere else?
A possible set-up is to:
include the bug-tracker issue ID in your commit messages in your SCM ("[MYPROJECT-12923] add this new option in that nice feature")
launch your build with Jenkins that retrieves the source code from your SCM. Jenkins will show you a "Recent Changes" label linking to a page where you will find the commits that took place between last build and the current one. The commit messages will include the list of issues ID included in the build.
Note: that maybe does not answer your question perfectly because those commits could be intermediate one. Depends also on how granular are the commits.
In our DEV team, all the commits have the JIRA number in them (This is enforced by a plugin called TicketIt in Stash . There are various other plugins available for different repositories) . When we run a build , all commits that are part of the build are aggregrated by teamcity and displayed on a tab called issues . This solution that I am proposing works in teamcity and bamboo . I am sure thee would be some plugin with Jenkins for the same.
A hackier way would be to get the start time of the last build (x) and the current build(y) and get all JIRA tickets that were closed during this time via JIRA API. This might not be a foolproof method if your JIRA's are not always closed before a build
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.
At https://github.com/yourusername/yourreponame/graphs you can find some nice graphs showing commits over time. However the information is only for the master branch.
How do I see the same information for a branch other than master, or see a graphs taking account commits across all branches?
If this is not possible, how can I at least see how many line of code have been committed under a particular branch via the GitHub web GUI?
Is any of this possible?
I just stumble on this as well. You can actually see the graphs for other branches than the Master branch.
On Github in your repo - choose settings.
In settings - change your default branch to whatever branch you would like to see the graphs for.
The help of Github: Viewing contributions :
Whenever you commit to a project's default branch (or the gh-pages branch), open an issue, or propose a Pull Request, we count that as a contribution.
So:
default branch
gh-pages branch
open an issue
pull request
only these will be counted.
As #Mikael 's answer, you can change the default branch in repo's settings.
Another help of Github: Which contributions are counted?
For commit:
Your commit contributions are only counted when they are created on or merged into the default branch or gh-pages branch of a non-fork repository.
I also want github to count all the commits, not specified branch :(
From what I can see, those graphs are for master only: I only committed on the branch gitlist recently, and my commit activity only shows those for master.
Unless you rebase your branch on top of a new repo you would create specifically for that kind of inspection, said branch activity won't be visible until it is merged back in master.
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.