(We caught up in IRC.)

We can't reproduce this issue, other installs haven't reported similar problems, and you're about two months behind HEAD. Please refer to this document for instructions on filing an actionable bug report which we can help you with:

One followup in T9573 but I don't think anything exploded, otherwise.

I also tried using the ref name (refs/tags/phabricator/diff/123) and the tag name (phabricator/diff/123) as branch names without success, so I'm pretty sure this isn't fixable on our side.

This basically works, but there's a minor problem which I can't fix on our side that stops things from working: CircleCI does not git fetch --tags, and does not fetch the tag explicitly when building a tag. It does resolve the tag, but never actually downloads the corresponding commit. This means that tags and other refs which are not ancestors of a branch head (which is to say: everything in the staging area) are not buildable. I don't think I can work around this because we need the commit to be fetched in order to make it to the checkout: post: step.

I think I misunderstood and by "size" you just meant "point value". This will happen eventually as part of other projects work (T9378, T3670) but those need to happen first. I'm not yet sure if we're going to make this a first-class value or let you designate a custom field as a "points field" or something else.

Your expectation is that a card worth 10 points is rendered 10 times larger than a card worth 1 point?

This is definitely something which can be improved -- the transcript has been updated recently and is fairly clear ("Forced Mail", "...ignoring notification preferences..."). The /mail/ UI is fairly clear too, but hard to find right now. Other UIs and interactions haven't been updated as recently and aren't as clear.

See also this in the transcript:

aklapper (Andre Klapper)

• Mail Tags: This mail has tags which control which users receive it, and this recipient has not elected to receive mail with any of the tags on this message (Settings > Email Preferences).
• Forced by Herald: This recipient was added by a "Send me an Email" rule in Herald, which overrides some delivery settings.

Branch name issues aside, CircleCI still isn't running builds for me, so I'm going to have to shelve this for now.

CircleCI still isn't running builds for me so I can't reasonably do step 4 (the webhook part) tonight. Presumably they'll be back up by tomorrow and I can finish this up.

The test engine can figure out if --everything is present or not but I don't think it can reach up to the workflow object right now. So you can disable arc unit as a sub-step of arc diff, but not without also disabling arc unit when run without --everything.

We can use a branch name like "zzz_harbormaster" or something so the console doesn't clutter up too much.

Is running arc unit interactively ever desirable? Can you either disconnect the integration entirely, or have it no-op if the --everything flag is not present (if you rely on --target for build integration)?

Right. If you put it on multiple devices, we can't choose a single identity when you try to do anything with that key. I don't actually remember why we're even allowing that at all and suspect it's some legacy stuff from an early draft that no longer makes any sense.

So it's fine to reuse a key across multiple hosts which are registering as the same Almanac device, but I shouldn't reuse that key for different Almanac devices?

Quotes also don't work in Ponder.

No, it's more like this:

Oh... so a single instance can register as more than one Almanac device?

I guess that my question here is two-fold:

Sorry, I don't quite follow...

I think I just configured remarkup.ignored-object-names wrong when I added S3, should be OK now going forward.

Try the diff PHID -- $diff->getPHID()?

So if I set that up to push a tag, will that be guaranteed to be on the remote before the build starts?

haha

sorry I broke CircleCI ;_;

Oh, it's actually been ~down for ~4 hours? Roughly since I touched it earlier this afternoon. o.O

Specifically, this is workable because requests like this are handled in a desirable way (note loldoesnotexist branch, which does not exist):

Here's the specific flow that I think is workable:

Okay, it looks like we can pass any ref-like thing as revision and pretty much whatever we want as branch, and branch is just completely ignored if revision is present, so building tags isn't an issue. We should be able to do a proper integration here cleanly.

oh

You can currently configure a "Staging Area", which will cause arc diff to push to a tag in an arbitrary remote as a side effect. I generally think this is a better way forward than pushing to named branches in the "real" remote, because it doesn't imply an end state where your remote has "master", "develop", and a million named branches that you can't get rid of. T8092 and linked tasks discuss eventually moving beyond this and virtualizing these refs so they're invisible to users but visible to the build system (for hosted repositories), but just using a different remote is approximately as good today.

It looks like that code isn't interacting with Harbormaster at all and is making an HTTP request to Changes directly from inside a Herald action. We (fairly strongly) discourage this as a way to communicate with external systems (see T5462 for discussion/rationale -- it's synchronous and blocks the UI, error handling can't happen properly, and there's no way to retry if it fails). There is no build target available during the execution of Herald actions and I can't really come up with a reasonable way to generate one.

Phabricator is not a good fit for your workflow, then, and never will be.

For example, here's a reasonable way you might perform these changes:

Increasing max_allowed_packet to a much larger number (say, 512MB) will likely resolve the 2013 error.

What is max_allowed_packet set to in MySQL?

Differential just can't load the change set into its database.

Yes, with caveats. See T7148 for discussion of why this is complex. Roughly, here's the state of the world today:

For those of you using CircleCI, what sort of integration are you hoping for?

Progress here:

It's just this thing, basically:

I'm broadly pretty happy with this after using it for a bit, at least for use cases we have today. It does feel a little bit labor intensive, but not overwhelmingly so, and all the stuff is pretty well linked up so once you get the hang of it you're almost always only a click away from wherever you want to be to do the next thing. It's also reassuring to be able to go to a blueprint and check what might be using it at a glance.

General progress update here: this now works, technically. Almost every part of it -- particularly, the UI -- is still total garbage for now, but if you ship a revision against rGITTEST up to this server you'll get a "Land Revision" button on it which has worked twice in the past and might work again. I would recommend extending the list of pasta varieties found in the pasta file if you want to try this (the button should appear and function without requiring the revision to be accepted for now, and everyone has write access to the repo anyway).

Releeph will execute all the same core display code and have all the same ingrained workflow assumptions. If your changes are too big to review in Differential, they will also be too big to review in Audit, and Releeph will not have dedicated review tools.

Please read this document carefully before filing a feature request:

I'm not sure there's anything we can really do about this. Gmail is applying a destructive transformation to outbound mail, and there is no inverse function we can apply to restore the original mail.