I think global + personal makes sense -- we'd want to put stuff like "New Bug Report" / "New Feature Request" there on this install, I think.

In T550#202580, @epriestley wrote:

Multiple hostname stuff: Today, the SSH hostname of an install and the HTTP hostname do not need to be the same.

We use this in the Phacility cluster: Phacility HTTP instances are at instance.phacility.com, but serve repositories via vault.phacility.com.

The technical reason for this is mostly that ELBs can't accept port 22 traffic -- or couldn't when I set them up. It looks like new VPC-ELBs may be able to accept on 22. We currently use HAProxy to balance SSH traffic and ELBs for HTTP traffic.

We could require that all hostnames be the same and change the cluster to bounce SSH traffic through the ELB to the HAProxy LBs and use new VPC ELBs, or put HAProxy in front, or whatever else. But this is probably more work for us than letting them differ.

There are also some possible arguments for using a different hostname for Conduit CLI SSH access (conduit.whatever.com) that has different DNS-based load balancing behavior than other SSH access.

The real working example

I've been playing with it for maybe half an hour, and couldn't reproduce:

• Made revision public
• stopped the daemons
• mention a user
• updated the revision to a new diff
• made the revision not-visible to that user (visible only to the acting user)
• start daemons and let them finish the queue

Thanks for the advice. That yields the trace below. My understanding is that it was a diff with policy set to subscribers which had an author plus a single subscriber. That subscriber was added by herald upon the diff's creation, so there's certainly grounds for something going on there. I had trouble divining the exact issue, but tinkering with the permissions for the object ended up letting the emails go through.

We used to have a tool to show a task's data, but it must have gotten lost in some refactoring.

• In Daemons, find the task ID in the leftmost column of "Leased Tasks".
• Run bin/worker execute --id <id> --trace to execute the task in the foreground.

That will give you a more detailed error information which you can paste here.

Just updated to head and am seeing the same issues.

I know it's closed, but here are few proposals (not sure if better in any way):

• base
• derived / derivative

The API is considered unstable and there seems to be work to do about this manual transformation from arc lint --output json (which isn't even JSON) to harbormaster message JSON format.

I think these are all reasonable things to want to do.

There may be some merit to changing the UI to say "Title" or "Error Title" instead of "Message", but this is so low in terms of value ("Admins that don't read docs confuse fields") that I doubt this will actually happen.
Changing the API is even less likely, because that will actually break other people's code.

Partially it is. I remember now, I've fallen in this trap the second time now, I forgot what name is (again, btw). I told you that name is too generic. The first time I found out that Message is a wrong title for Linter rule name and worked around it. This time I forgot it again, because the terminology is not consistent.

OK, looks like this is just a case of miss-reading the docs:

• name (optional) Text summarizing the lint message. For example, "Syntax Error".

name in the regex does not mean "Name of linter" but "Title of error".

It's my own script. I haven't found anything like this in the sources. I also haven't found any hints how to integrate`arc lint` without pain (no --target option like for arc unit).

cat is slow to appear

I see cat :)

ok now cat is in feed

hmm, cat no show in feed

It's doing it again now...

What made the translation from the string-after-regex to the harbormaster json structure in your example?

Yes, triggers sound like they'll do the job. Not to say search and filterability still wouldn't be handy in more ad-hoc cases. Triggers require foresight.

I've just noticed that arc lint --everything output summary gives me this:

I'll try to give an example which makes clear that linter message is not meant to be linter name.

Talk to your administrator, they've changed your installs permissions. If you have other questions on Phabricator, please use Conpherence or Ponder. Feature Requests are for ... well feature requests.

Unfortunately this probably isn't something we'd pursue in the upstream, so we won't likely take code into the upstream for it. We allow people to share things like this though on the Community Resources page in Phriction

T5055 also covers distribution of linters/etc via arcanist as a package manager.

OK. to decrease the deploy cost. i would like to contribute the project. try my best to do this work. I am not ask you provide it for me . Is it an opensource project? Every one can contribute it ? but i still need your guide. if i want implements. what the problem block us do the work?

T6012 covers composer, T4200 covers alternate installation methods. In general, I'd assume you're installing all developer tools (if you're a large org) via some scripts, and scripting the installation of arc/git, is trivial. arc upgrade can be ran locally to keep developers up to date.

Not really, I'm still not sure what the root problem is. It mostly sounds hypothetical. In general you're asking us to do weeks of work to save 1 engineer 5 seconds, 1 time over the course of their job. At least, it seems like if those few seconds are so vital, that you'd script all developer tool installations with one script. I don't see what 2 repositories vs. 1 solves.

@chad. i tried to explain why i post the feature request. it it ok? valid for feature request requirement?

You didn't see this at the top of the Feature Request form?

Well, i have not found a feature request template. but i tried to explain why i post this feature request.

See Contributing Feature Requests for what information is required for a feature request.