User Details
- User Since
- Apr 28 2011, 6:55 PM (708 w, 2 d)
- Availability
- Available
Apr 21 2017
It would be useful to extend this concept to the lifecycles of other Phabricator objects, not just Maniphest tasks. For example, people on my team have sometimes wanted to see a histogram of how long it takes Differential diffs to get reviewed, especially if we can break it down by author and/or reviewer.
Nov 1 2016
I'm specifically interested in the arc diff --try part of this and would want that to be the configurable as the default behavior. For an installation that's using things like CircleCI integration to run tests asynchronously on a build server, it seems very plausible that reviewers will sometimes fail to notice that tests haven't finished running yet, which will lead to people landing broken code.
Jul 18 2016
Obviously I can implement this myself locally, but if it's a lousy idea for whatever reason, I'm hoping filing this request will cause someone to warn me off it.
Aug 20 2015
By default, and the default is used in basically every project I've seen, the "run tests" command in Maven will do a build first. An analogous Makefile would be something like
By "One option that would work" I meant, "One option that would work in a world where a single command can be both a linter and a tester," in case that wasn't clear.
That pattern is definitely possible, but the "make or whatever" step can take a noticeable amount of time on a complex project even when there's nothing to build, so you're kind of faced with choosing between "minimize time to lint errors" and "minimize total time for a successful diff submission."
I've attached
just so we have something concrete to talk about. Right now this is sitting in our source repository and we load and run it via .arcconfig entries as you'd expect. It is much closer to a "run everything" implementation than a highly selective one, though it is able to deal with repositories that have multiple Java projects (where a "project" is indicated by the presence of a pom.xml file) and will only run tests in projects that have changes. So for source bases that have code for multiple server components, it'll be at least somewhat selective. And if the pending change list has no changes in any Java projects, it won't run anything. (Obviously this has the potential to be wrong if, e.g., a change modifies data files that affect a test, but it's likely to be right in cases like a repository that has both front-end and back-end code.)Aug 19 2015
May 8 2014
Strike that last comment about tooltips; I see they're already there.
Feb 28 2014
For what it's worth, here's a little intro document I wrote for the company I'm helping out. Company-specific stuff replaced with XXX here to make this easier to reuse if anyone wants to reuse it. If you don't mind, I'll also copy-and-paste a lot of what you wrote. They are a pretty small shop with just a few generalist developers of more or less equal responsibility, hence the recommendation for everyone to add Herald rules to make themselves review everything.
My approach to answering these questions is to basically say, "Once you're using Phabricator, Github becomes a dumb git repository server and you should just completely ignore its UI." I hope that's actually true.