There's nothing specifically actionable here so I'm going to close this. We'll probably expand states in the future, but I think many/most/all of these cases only differ in what they're labeled, and not in the actions the system takes as a result.

I don't think this is meaningfully distinguishable from logs. There's no reason a target can't fail for multiple reasons, there may be other non-failure data targets wish to log, this data essentially has to be text which we can't understand or do anything special with and I don't think it makes sense for us to do anything about it anyway.

I'd still like to wait for someone to hit the, e.g., Russian + Spanish problem in case more complications arise between now and then, but that allow-a-map solution seems relatively upstreamable to me when we do.

I suppose we could do something like this, hypothetically:

That will technically work as a local patch, it just isn't extractable by translation tools.

This isn't currently possible.

https://secure.phabricator.com/book/phabricator/article/custom_fields/

This should be fixed now (see rSVNTEST1).

See http://www.phpwtf.org/poor-parser-easily-confused

Yeah, you should be good to go -- I don't think there are any surprises here. The old code just nuked the actual data since it was written in like 1950.

Presuming this is fixed for real now, let us know if you're still seeing any issues.

(I did fix a couple of similar things a while ago, so it seems reasonable that this may be resolved at HEAD.)

Oh! Sorry, ignore me.

Yeah, you're about two months out of date. Does updating fix the issue? See:

The specific UI (Phacility → Instances → (Choose an Instance) → Adjust Configuration) in question doesn't actually use PhutilJSON to format the output right now, so it's still rendering the less-preferred form:

I guess you can conceivably use some static property somewhere to coordinate a lint engine and unit test engine in a hacky-but-functional way.

Generally, since we don't have access to your hosts or to any monitoring or logs, we're relatively powerless to help you resolve operational issues which can't be directly reproduced and which other installs don't experience. We can chip away at this stuff, but there's a lot of fishing involved and progress may be extremely slow (T8588 is a similar issue, where we've gone through multiple rounds of investigation and back-and-forth without truly making much real progress).

Do you have any more specific details about what happens here?

This is at least somewhat our fault, behavior on nano foo<tab> is different from arc upload foo<tab>. There's probably some shell-specific magic in there too, of course...

Realistically, your use case is just way outside what Harbormaster is targeting or what I consider reasonable for a general-purpose build system to have in its core set of capabilities. It is not going to support these sorts of things for a very long time (years and years).

If the artifact is literally a binary on disk on that server, and you want to be able to restart part of the build from after that binary is built, I think we have no choice?

(I'm generally not huge on content source being especially useful anywhere, but it's occasionally nice to have for debugging, especially for Conduit/Daemons content sources..)

Or do you mean exposing it in the UI? I don't think it's too useful, but it might be helpful to see if someone is mobile vs web, maaaybe? We could put an icon on their picture or something though. I think all other cases of content source don't matter.

It's just on the transactions, right? Not rooms?

I tend to agree, mostly, but I think D9807's global-namespace-on-artifacts thing isn't the best approach.

I'm just going to close this in favor of T8783. If we build this it would happen via Nuance importing pulls as revisions, not Harbormaster being specifically aware of GitHub pull requests as a buildable, at least in the upstream. You're welcome to do something third-party and implement BuildableInterface on it, which might be a plausible approach, but isn't something I'd want to do in the upstream.

Harbormaster is now unprototyped. See T8089 for more focused/modern discussion.

We currently allow any message, we just don't do anything with messages we don't understand. Possibly this should be made more strict, but I imagine accepting any message and possibly letting extensions handle them in the future. We might not be able to figure out if anything will accept a message or not when we receive it.

(under certain, unknown conditions).

then it is totally invisible to the reviewer that the patch relies on X()

When merged, it took with it all changes between bB and bA into bA.

I want every change to the code based to be explicitly accepted before it's landed.

In T9109#130675, @hach-que wrote:

You would be better off setting up the linters / unit tests through arc, and then making gradle run arc lint and arc unit as part of it's process.

The fields that are updated depend on the server configuration, which is why they aren't enumerated in the help.

T2543 is also likely to add a formal "wip/draft" state soon for "this isn't ready for review yet, but I want to share/get comments on it".

Essentially, the issue here is that tools such as gradledont have any east way to run linters/tests on a subset of the code base. It's possible to write a linter which wraps around ./gradlew check but this means that arc lint -- file takes the same amount of time and resources as arc lint --everything .

Why do you care about this information?

This is something I've been thinking a little bit about recently, too, although I don't have many ideas or much of a plan yet.

Are people supposed to be able to see the repo if they are not in the project but in the space?

The default policy for x/y/ is inherited from x/. The expectation is that this is always the correct default. What's your use case where this isn't the correct default?

You have to be able to edit x/ to create x/y/. The UX is kind of junk, but I think this does technically work. Is that sufficient?

(This command may take a while to run since I was extremely lazy about loading the data.)

We don't actually store the outcome of preference filtering at the time we sent the mail right now (we will after T5791) so I can only report an "Unfiltered" column, which is the maximum number of messages we may have sent (I could do a little better than this now, but it's probably better to hold it until T5791 for a more complete picture). Users with any settings which disable mail will have received less mail than the "unfiltered" number.

This could be more flexible (there's no real way to report logs or artifacts yet) but lint/unit work fine. We'll expand these capabilities in the future.

This report is about a year old, things have changed a lot, and I haven't seen other reports and can't immediately reproduce it.

This has changed a bunch and I haven't experienced any difficulty with it in the last year or so.

Well, no level other than 0.

Yeah -- we can pursue that stuff, but I'm strongly suspicious that user complaints about mail volume aren't meaningfully correlated to actual mail volume and that there is no level we can drive it down to which will meaningfully reduce user frustration.

And I generally agree about dependencies and externals getting ignored for now, but I'd like to assume we'll eventually support both and plan around that.