General Chat
Come, chill, and stay a while

Nuance will let users communicate without an account.

Good morning. How-to question - When you use the arc diff --preview tool, the URL you get to link to gives, of course, very a very nice diff view. Very useful. There's also a button to click to generate a revision, which brings up a page to fill out. Question - is there a way to auto-populate any fields? (specifically the Title field, but others would be nice) Thanks!

If you omit the --preview, it will take title and summary from the commit messages.

Thanks Avivey, Challenge there is that in our SDLC, the decision to make a rev must be made *after* diffs are viewed. So we're still looking for options on this one.

Pre pre commit review?

Even before that. Developer tool.

Is there a very compelling reasoning behind this workflow?

Ummm...... the boss said so? And the boss signs the paychecks?

Ok, that's a form of reasoning, I guess.

TechnoTrumpet added a participant: TechnoTrumpet.

Hello! I made a test phabricator. Is there a way to keep it from being destroyed?

Feb 21st, 2017

Backups, backups, backups... (location, location, location?)

@jimh - that sounds like a very odd case of needing to do a pre-review prior to the review. maybe if you could find out what the need is for that there might be a different solution

does phd have other logs than the ones in /var/tmp/phd/logs ?

phd keeps dying here but there's nothing interesting in those logs

but only after like 24 hours

other than failed calendar imports (But that doesn't seem very critical)

ah well, I'll use systemd to auto restart it

Maybe they failed to write to the logs?

dthomas removed a participant: dthomas.

Recently updated to stable. Not sure when this feature was introduced but my users do not like the "noise" (their words), is there a way to silence the emails for it globally or disable the history item altogether? :-/
"Harbormaster failed to build B32133: Diff 76185!"

Hm. Additionally, "https://peppy.apple.com/feed/query/all/" Feed is displaying very old commits. It seems to be slowly walking through our "ancient history".

Any ideas why that might be happening? (as in, what did I screw up? I just followed the upgrade instructions and the resolve setup issues instructions.)

Was the install very old? At some point we started importing tags, so if you just jumped that point, you'll get a lot of those events.

You can stop it by putting those repositories into "importing" mode

"Harbormaster failed to build Diff 76185" is a little less clear... Are you sure it says Diff and not Revision or Commit? Is it only for new revisions?

The install was from last June I think.

We have crap tons of tags. >_<

It seems to be for either for a new revision or when a revision has been updated with a new diff. The text of the email and the history item both have the same text "Harbormaster failed to build B32135: Diff 76187!" (rest of email body is typical for any PFR event; history item only additionally has a timestamp and a red icon).

./bin/repository mark-imported --mark-not-imported <repo> should stop if from generating more of this noise...

Would it be better to just let it finish it?

I don't care too much if the feed is weird for like a day or two.

It will continue to work, just won't generate the event

If it just for new revisions, that it means the new revisions are failing tests/builds/whatever, so calling it "noise" is a bit funny. I don't see a way to disable HM mail in user prefs.

Maybe they should write better code, or fix the build, or disable the build for revisions :-)

Ah I see. Do I need to run something to let it generate events again for later things?
Yes, it is "funny", but we have automation that posts a comment with actual error messages (inside a scrolling "code" block), so it is currently generating two emails.

If there is a new better way to have those error messages piped through during the event, I would be happy to use it instead though.

oh, that makes more sense :)
when it's done, if it doesn't automatically say "imported", you can run ./bin/repository mark-imported <repo> to turn it on.

The existing pipeline supports Lint errors which show as inline comments, and build errors which just show up as a red X, iirc.

no support for actual error messages being displayed on the revision page yet.

oh, it shows "test name" and status - failed, broken, skipped, pass (Which isn't shown).

(T9951 is probably the closest ticket)

Side question -- we have unit tests being run as a harbormaster plan in our "CI" farm on revision create/update; how would I get that to show up in the "normal" Differential unit test UI? Or is it only possible for local unit tests from arc diff ?

It goes in to the harbormaster.sendmessage conduit call - it accepts test information and shows it there.

Cool. I'll let our "PFR Build" engineer know about that.

A couple more annoying questions from the semi-newb phabricator admin:
What is the difference in terms of email body content for a git diff vs unified diff?
Is it possible to show line numbers in the email body content for a diff? (currently we have an ugly script that parses .patch file and edits the email body, but it's way uglier than the default)

I can't think of a reason needing line numbers in email would be important. If your diff is that long, it shouldn't be reviewed over email.

I believe we limit the size of email diffs anyways

I think the line numbers more for ease of local reference in file for folks who don't like using the website to get more context. I use it sometimes when I cannot VPN in to use the website. I experimentally set metamta.differential.inline-patches to 999999 lines to see what it would look like.

It hasn't choked on it yet.

We don't consider that to be code review.

Getting additional code content is not code review?

Generally, we try to focus on tool that increase code quality and make the review itself thoughtful and complete. Doing these over email bypasses a lot of that, and I don't think we'll likely ever recommend it for anything other than small, short patches.

( I chose an arbitrary large number for the setting b/c I didn't much want to think about a maximum, I just wanted to test it with whatever was coming in. It's an entirely unrealistic number. )

Yes, well, some engineers dislike change and like their email apparently. *rolls eyes* I'm only trying to get them off my back about their dumb email PFR preference that is contrary to the rest of the team. I am not terribly happy about supporting it.

But the boss says I have to.

Yeah, understood.

Did you tell them about arc patch? They might like it, because they can then use git diff or whatever.

Feb 22nd, 2017

If I wanted to silence all harbormaster emails (for now until we can merge our automation messages w/ harbormaster transactions), would I find every id(new HarbormasterBuildTransaction()) and add to it ->setDisableEmail(true) ?

@avivey It was like pulling teeth to get them to go from a git alias (i think git senddiff?) to arc diff. :-/ I do know a couple people on the team that uses the web UI that use arc patch as part of their review process (usually for reviewing UI changes to the app). I wish it was easier to automate creating and sending along screenshots of the app as part of a diff when it's UI related...

hello guys) please tell me, can i enable badges and Calendar prototype applications without any headache to our work?

I mean, is not broken there something in our phabricator now or later, with updating of these two prototype applications?

I have all prototypes enabled with no headache. Some are more, some are less usable ;)

Anyone know what might cause two different "username closed D## REDACTED by committing rA#### REDACTED" to just keep showing up in the Feed over and over and over? Every few minutes these two just show up again. Other *real* events are occurring and showing in the Feed between them when they happen.

(Or how to properly debug it?)

rsmarples added a participant: rsmarples.

When creating a workboard for a project, there is a checkbox to say "Make this the default view". Is there a way to toggle that after it's been created?

wish it was easier to automate creating and sending along screenshots of the app as part of a diff when it's UI

These things are mostly hard to automate because "Find the UI stuff that changed" is a very hard problem. But my flow for this is to use arc diff --browse and then print-screen and paste screenshots into a comment or into the Edit Task window.
If you can somehow solve the "Find UI stuff" (Maybe have a name for each screen, and put those names in the commit message?), it shouldn't be too hard to have harbormaster/bot make a build, load the right screens, and put on the right screenshots.

ok, it sounds like a lot of work, actually, but possibly worth it, if it's very common.

@chad Awesome! thanks.

@avivey For iOS projects that use .xib files it's probably not too hard to do. For most projects that build UI out of code (most games, some apps) much harder!

sachinag added a participant: sachinag.
robertkraig added a participant: robertkraig.

So is this now the preferred method of interaction over freenode?

some still hang in freenode, but we haven't recommended it in probably 1-2 years

I seem to be having an issue with a herald rule that has "Commit is on auto-close branch" (the commit in question is on "master") and "master" is the first line of "Autoclose Only" for the repo in Diffusion, but herald transcript reads: "Failed Commit is on autoclose branch". Any ideas? :-/

(The commit appears on master and two other non-autoclose branches. Other commits have properly matched the herald rule, although they were [eventually] on multiple autoclose branches. We are using git.)

Feb 23rd, 2017

That might be T11953 and friends, @mribau_a; there's still some issues there...

mariyajane15 added a participant: mariyajane15.
mwek added a participant: mwek.

Does anyone have an example of using differential.creatediff Conduit API? I'm trying to make a mercurial hook that will create a code review based on a code change, and looking through ArcanistDiffWorkflow I'm a little intimidated at everything it's doing to call that method.

There are some things I can take for granted (always gonna be mercurial, diff will never include binary file changes, etc.)

Err, specifically the changes field is what I'm trying to divine

Feb 24th, 2017

@cspeckmim: can't you just use arc diff in your hook? --preview for "no revision" and --raw or --raw-command to have an alternate source for the data.

p_sakzhang added a participant: p_sakzhang.

@avivey - that crossed my mind but our existing hook would have to be scrapped b/c it happens prior to the commit transaction happening for arcanist to be able to see it. It'll probably be what we end up doing but was hoping the scary PHP wasn't so scary~

Also means we have to install Git, PHP, Arcanist on the server, which probably isn't a huge deal

Try differential.createrawdiff if you haven't already? diff is just the full raw blob of text you get out of git diff.

(Building changes with anything other than arc is enormously difficult.)

@epriestley - Thanks, I appreciate the tip!