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.

It's supposed to be sent with the call to the external build system, but that doesn't seem to work either -- the build target phid received is always ''.

I'd be inclined to show N branches, for some small value of N like 3 or 5 or 10, with a link to "Show 1,695 more branches which contain this commit...".

Actually I think we can go even deeper (T3462).

This has been fixed in master and cherry-picked into stable (as rPc0a52201). You should be able to update to pick up the fix.

Unfortunately, no part of that sounds well-aligned with our thinking about the roles for these applications or our roadmap for the products. If your development workflow routinely has changes which are too large for Differential to reasonably accommodate (20K+ lines?), it is far outside of my experience in software development and Phabricator is probably not a good tool to use for this workflow.

Not sure if any of this is relevant to T8297, but everyone loves walls of text!

I think that change is tentatively within the realm of reason, but I have some concerns.

You have a version of cURL which has a bug with Content-Length (see T8654 for discussion), but your version of libphutil should include a workaround, so I'm not sure what's up. I can't reproduce this problem on this server.

At HEAD:

Can you show me the output of these commands on the server?

Other known demons are spaces (T7305), colons (T7341), and sort-of-but-not-really hyphens (T9480).

Blueprint selection (which got more details in T9519) is now in a rough-but-functional state so I expect the rest of this to move forward shortly.

You can change the configuration. This protocol is not prevalent enough to motivate us to include it by default in the upstream.

Particularly, the command server wire protocol is completely different from the HTTP/SSH wire protocol (and pretty reasonable overall, although it's solving a much simpler problem).

We have some CommandServer stuff too, although I don't think it has ever been reachable from the UI. I don't remember if the original use case was improving arc performance or improving import/parser performance.

So we probably need to special case the unbundle command, decode the response, build additional parts from stderr, and then insert them into the response.

I suspect it's worthwhile for us to support bundle2 eventually. As far as I can tell from my investigations in T9450:

Technically, we could implement "To", "Cc", "Any Recipient", and maybe "Sending application" or "Object type" outbound Herald fields today so you could write some variant of this:

Well, I don't expect to actually fix any of this for like 20-30 years, I'm just filing it.