(And the project description can be used to document what the project means, how to respond to it, etc. And you can search for revisions with those projects, etc.)

Flags are personal bookmarks (other users can not see your flags), so I think they aren't compatible with your goal. You want everyone looking at a revision to be able to see the note, right?

I'm going to merge this into T9537, which has more discussion and an additional use case that I find slightly more compelling as a motivator (numerous targets in the remote).

Can you show me a screenshot of an example that demonstrates this problem? It's hard for me to imagine what sort of warnings are valuable enough to raise but not valuable enough to fix.

Given that, I think the fundamental feature request here is for arc land to target a temporary local branch that is used just for staging and pushing the final commit, rather than targeting an existing local branch.

I'd recommend looking at exactly what arc does and following that, rather than trying to construct calls from scratch.

Why are you trying to create revisions with a direct API call? Can you describe the broader problem you're facing? There may be a better solution. See:

The name "Pipeline" brings "Data Pipeline" to mind for me, possibly because AWS has a product called "AWS Data Pipeline", although it looks like no one else particularly likes "Releeph" either.

Yeah -- at least in HTML mail, the cows aren't getting properly linebreak'd either. I don't think that's new but it should be pretty easy to fix.

That seems tentatively fine, although it may only solve some of the problems here and may create new problems.

This may all sort of be moot since there might be a relatively unambiguous approach to T9082 and this which uses a rule like: if the target does not exist locally, but does exist in the remote, use a separate workflow.

Well, it is essentially releasing into a non-production environment. We may then want to promote the artifact from the test environment to production.

Yeah, they're a bit different. There's some nuance here, but basically T8620 is talking about landing from a detached HEAD, and T9082 is talking about landing without creating or interacting with a local target branch (usually "master"). This is potentially talking about both, I think, although more on the T9082 side.

I think this is about the same as T9082, does that sound right? (Is that a report from another team member on your team? This workflow seems completely unorthodox to me, although maybe it is less bizarre than I imagine.)

I'm pretty sure that if execx() an editor like vim or nano, whether you use bypass_shell or not, it just executes it uselessly in the background and hangs forever. That is, the behavior of these two programs is very different on Linux, and I believe it will be very different on Windows no matter what bypass_shell is set to:

How does that obsolete PhutilExecPassthru?

D1938 is the actual origin, I think.

Oh, that diff just moved it, so it's actually older than that.

Possibly. We've used it in PhutilExecPassthru since D6774.

D14246 / D11396 / T6966 are about a specific Windows issue where the command name is treated differently from other arguments. That is, these commands mean different things:

whether upstream wants to wait until it can tackle the generalized problem, or whether you'd be okay chipping away at smaller use cases first,

Ideally, just use a mail client with filters that are powerful enough to do full header matching.

providing an option to send email to a mailing list address associated with a project

Yeah I don't know why you would want to duplicate Audit details to Maniphest. Do these commits have a single merge commit which could be audited instead?

To clarify on my terminology, my eventual goal is to have the following environments:

The cost is probably small at the moment because we are only talking about an application server, but in the future I'd expect a QA environment to consist of:

Haha, no problem. I just mean:

Sorry, I don't quite follow... (It's early and I'm still somewhat jetlagged... I'm in Vegas for AWS re:Invent at the moment).

Is there an unavoidable cost to keeping QA environments up for multiple days?

I have a somewhat similar (although much more complex) use case. Basically, I want to eventually have the ability to spin up a QA environment from a diff. Currently we have developers do this manually, which means that the instances sit dormant for hours to days until the QA person is able to test it. Instead, I want to build a "Spin me up a QA environment from this diff" button into Differential. Roughly, I expect this to work as follows:

+1 on "Pipeline" instead of "Releeph".

Yeah, this is still feeling pretty reasonable to me after thinking about it for a day or two.

This is definitely confusing and something we should fix. (We may get it from T9132 cheaply.)

I also sort of vaguely want to just rename Releeph to "Release". I don't actually know the origin of the name but I don't think it makes sense? It's just a word that sounds like "Release" but has an "f" in it? Why isn't it "Relieph"?

(I can also make a Community Skunkworks space or something for nefarious plotting if scope expands here, but I think there's good alignment with my vision for Releeph, triggers like Pipeline, your actual requirements, Harbormaster/Drydock starting to get useful in general, and plans for letting Phabricator do repository writes in T182.)

Oh, I actually meant "Releeph Branch" not "Releeph Product", I think. Products are like "The iPhone App", branches are like "The iPhone App, 2012 Week 29". Branches could be renamed to "Releases" reasonably.

There is a similar problem elsewhere of roughly "which of Debian Jessie, Debian Kraken, and Debian Longhorn is this bug fixed in?", where releases are mutable, and our stable "releases" are also mutable, and Facebook's www deploy is mutable, and Releeph currently spends most of its effort on making products mutable. But it makes sense that a large class of releases might reasonably be modeled as immutable, especially if they have meaningful build steps.

Broadly, here's where I think the closest mappings to roadmap/starmap stuff are:

In your situation, are releases mutable or immutable? That is, if you create release 3.11 and discover a bug in it, do you merge/cherry-pick the fix into 3.11 or do you throw 3.11 away and create 3.12?

Specifically, I think your ultimate call parameters should look something like this, if you are purely reporting coverage and not test results:

Yeah. If we did the bar UI, I think the length of the bar is just "U + C" (divided by the longest bar shown on the page, I guess? Or like log-base-something of that so the absolute length of the bar always has about the same meaning?) with something like "C / (U + C)" percent of it colored in.

See also:

Yes, you can use harbormaster.sendmessage to report coverage information and unit test results. The API call has fairly thorough documentation on the console page:

I'm tentatively OK with upstreaming that if we can find a way to present the data that communicates both the coverage percentage and total line size of each directory. In the screenshot above, the current directory might be nearly uncovered if async_diff/ has 95% of the code, or well on the way to coverage if submit_queue/ has most of the code, right?

Phurl is a prototype application. See:

Well, that was easy.

Oh! How could I forget about this unique, distinctive logo?

I don't think we actually have a vector version of this -- the original was through 99designs in 2011 before we had a real company and I was much more interested in getting a logo idea than a production-quality set of assets, as I figured I could always go trace the thing in Illustrator later given my boundless innate artistic talent:

Short answer is: yes, eventually, but it's not something I plan to prioritize in the near term.

I can't reproduce this:

D14243 should fix this. You can cherry-pick it safely if you don't want to upgrade yet, although cherry-picking changes to the Celerity map may be tricky.

I can get this working over HTTP by just removing the special casing around the "unbundle" command. However, doing this prevents hg from emitting errors from commit hooks.

Yeah, that makes sense. Neither Travis nor CircleCI appear to support Windows at all, nor does Codeship, nor did ship.io before shutting down. And all of them just build off GitHub. So I think these are all very low-complexity build systems from the Harbormaster / Drydock / Jenkins / Bamboo perspective, but it makes sense that a lot of consumer web software doesn't need more than "build master off GitHub on linux".

Broadly, since I'd expect humans to sometimes run all the things that Harbormaster runs (to test, debug, profile, extend, etc., them), I'm assuming that this per-platform complexity should usually be pushed into projects so you can give humans one build process instead of separate per-platform build processes.

So both the ".sln" file and Harbormaster have essentially separate copies of the same platform-to-build-steps ruleset? Why isn't it "Protobuild.exe --generate" for Harbormaster, too?

If you were telling a human how to do the MonoGame builds, you'd pretty much point them at a wiki document with like 10 different sections, each of which had different steps and build commands on it and discussion about platform specifics? And they'd go through 10 similar-looking but ultimately separate build processes?

Can you walk me through why you have so many build plans? I understand that you might need one per, say, technology stack or team, but I don't understand why you'd ever have 100 unless you had a very large number of teams/projects, in which case I'd imagine it would be very rare to want to reconfigure any meaningful fraction of them at once.

Defining the v0 of this in greater detail -- largely just me thinking out loud:

We are also likely to build some sort of consensus framework (primarily to solve problems in T7639 / T7148) which provides generic support for "N of M users must approve this". This is a cleaner fit for having peers reset your MFA than putting a second weird review step on the merge pipeline, but maybe applicable at some point down the line.

I think we're ready to start laying in some of the groundwork for this. Per T9252, we now have hosted builds of commits and revisions in the upstream. This code still needs additional work and is missing a lot of generality, but the fundamentals seem to be in reasonable shape and I think we're on the path to stability.

Per T9252, we're now building all the repositories and all Community revisions, so the meat of this is working. There are still a lot of pieces that need refinement or generalization, though, or aren't even theoretically useful to installs other than this one for various reasons.

We are now building all of the repositories, and all revisions submitted by members of Community.

I'm not aware of any actual problem faced by installs today that the proposed feature is the best solution to -- nor can I imagine such a problem, even hypothetically -- so I don't plan to pursue it.