- User Since
- Jul 22 2014, 7:46 PM (361 w, 17 h)
Dec 31 2016
Apr 21 2016
Mar 8 2016
Feb 13 2016
@jhurwitz and I made some effort toward this mid-last-year, but the backfill script is still not quite working. Figure I'd put up the progress.
Jan 14 2016
There are many existing failures in our codebase. Linting all files would give copious (unhelpful) output. That being said, I haven't tried it because it would (probably) take hours to run. Should I give it a try?
Jan 13 2016
Jan 12 2016
Dec 12 2015
That prioritization makes sense to me. It doesn't seem worth putting a lot of effort into optimizing the workflow for a bad configuration.
Dec 11 2015
I was able to get some metrics for how many revisions have lint errors in this particular project (repo callsign 'C') with this query:
Dec 9 2015
- In this case I was yes.
- We have post-push builds hooked up, but not pre-push for this project in particular. (rely on arc unit)
- We have tests only run on affected files, but we have certain files that can trigger a lot of tests.
- I'm all for this (reducing some big categories from warning to advice by default). Going to try to make it happen. Would be cool to have a list of "top errors in this project" somewhere to make this process easier.
Ah yes, this should be a feature request and not a bug report. Sorry!
I saw it as two subproblems
- Difficulty remembering whether lint or unit failed
- Difficulty remembering excuse for lint failures in particular.
Nov 25 2015
Fix comment from 10->60
Only change the constants. No extra option
Nov 20 2015
Increasing seems reasonable to me too. The problem I see is a 4.1MB gif which doesn't get thumbnailed for the pinboard view. It's not a major issue, but it seemed one that was avoidable.
Running unit tests
Nov 14 2015
+1. I agree that conflicting rules are un-resolvable (and thus a configuration issue), but in this case, even consistent rules cause an issue.
Nov 13 2015
Oct 28 2015
Sep 14 2015
Nope totally sounds reasonable.
I think the thing that was weird to me was that I was able to accept from the UI after it was already in an accepted state, but since I had an old session, sure do it twice.
I honestly am not sure how I ended up in the state where there were two commits against one revision. I was splitting one revision into two and unfortunately, I'm not exactly sure what I did at the time. I believe it was a git rebase -i HEAD^ followed by git add -p followed by git commit and git rebase --continue, but there may have been some more nuance to it.
Sep 13 2015
I'm don't see why the number-of-rules is relevant
Ah you are right. You can see the set of conditions that were checked for the rule.
In my particular case, I wanted to find the rule that was adding me as a subscriber and disable it.
I ended up typing "/herald/rule/(rulenumber)" into my URL bar to get to the page of the rule.
Sep 12 2015
I went back to repro this and realized that my repro steps weren't perfect. On second thought, this seems like an expected behavior, but it still threw me for a bit of a loop. I had created one commit and split it up into two (the first of which was trivial and could skip review). I think the behavior is reasonable - I just didn't realize why it had associated branch A with the revision on branch B.
Jul 30 2015
Jul 13 2015
As a tangent, this flow also leaks slightly in that the end of arc land output says "you can get this commit back by..." and the SHA that it tells you is the SHA of the merged commit, not the tip of the branch that you originally had.
Jun 12 2015
Sure. I'll try to describe the problem we ran into.
Apr 11 2015
Feb 28 2015
Dec 12 2014
Sep 23 2014
Sep 18 2014
Got the backfill migration script to work on DifferentialTransactionComment.
Still can't quite get it working in the general case. I feel like I misunderstand
PhabricatorApplicationTransaction and PhabricatorApplicationTransactionComment
Aug 30 2014
Moved logic to remarkup rules.
Couldn't quite get the backfill migration script working. Looking for some help there.
Otherwise, it works great.
Aug 5 2014
Jul 24 2014
Macro was targeted at myself of course