We need something like this too because the exporter doesn't include points at the moment.

Could this be closed now that Phab supports this? (in /settings/user/Username/page/notifications/)

(Another possibility is to add behavior to arc to control this.)

Maybe. Another possibility is to mark builds as "nonblocking" in some sense. There are some other open requests for defining "advisory" or "noncritical" builds where build failure doesn't cause the Buildable to report a failed result overall. If we end up adding this state to builds anyway, it probably makes sense to include a "Does Not Block Review" flag to the "Does Not Fail Buildable" / "Does Not Block Dependent Builds" / "Failure Is Totally Meaningless" / Whatever flags.

The harbormaster builds that we have running on revision creation can sometimes be rather slow; they're builds in our primary CI system, but with less of a priority than jobs in the submit queue. This will result in 10-30 minute delays for every revision in our monorepo. I understand the preference for only adding configuration settings when absolutely necessary, but since this may result in a significant time sink for any installs with expensive builds, is it worth keeping something around like differential.initial-state?

For any body still interested, the project was in PHP, I had to rewrite in go, so it can be used elsewhere.

Pretty sure T7704 is the same as this.

PHI181 has an entangling concern (T11372).

Generally, this sort of discussion is better on Discourse (https://discourse.phabricator-community.org) than here.

From T10109, we shouldn't make revisions "Buildable" to Herald if the update is an automatic update in response to a commit being discovered.

Ah, thanks. I think your guess is right. I'll make a note in T2543, should be a one-line fix I think.

From https://discourse.phabricator-community.org/t/644 - it appears that HM now triggers a build on revisions when they are closed via landing, which fails because the build expects a Staging ref. I don't have the setup to test any of it, but the latest revision landed here doesn't show the behavior, so either f7f3dd5b2084 hasn't rolled in here yet, or that user is doing something funny.

In T8552#233072, @mejaz wrote:

Why is Phriction being kept on such a low priority? This task has been since 2014 if we take into account this: T5254: Allow top-level wiki doc to display entire document hierarchy instead of only 2 levels

Why is Phriction being kept on such a low priority? This task has been since 2014 if we take into account this: T5254: Allow top-level wiki doc to display entire document hierarchy instead of only 2 levels

After all that stuff:

Additionally, arc diff no longer dispatches ArcanistEventType::TYPE_REVISION_WILLCREATEREVISION if the server is sufficiently modern. (It no longer uses the datastructure this event received.)

See T2543. The flags related to previewing a diff have changed:

oh, nice work, it will trigger parent task as well when subtask changed, seems I need to add the "condition" like subtask status instead of a "action" for this... any samples? Thanks!

Question: When subtask was fixed, the parent task want to have a action, for example, add a tag or change status if all subtasks were fixed.
So how to get this work in the extention of herald action? Thanks in advance!~

This is technically accurate but real awkward for humans:

I pushed secure004 with that patch and it worked fine, although mysql came back up fast enough that we didn't have to wait. Since I don't have a way to actually trigger this condition, I'm going to assume this is resolved until we have evidence otherwise.

This has been stable for about a week now.

This traffic eventually stopped on October 20th.

The pruned (at 0.15 threshold), optimized ngram index for the original affected instance is only ~13GB, which is entirely manageable with the changes to backups, and we haven't run into other issues.

We hit one of more of these (db024) last week so D18725 should fix it.

In T5463#172345, @florianb wrote:

I ran into the same issue, it turned out, that the permissions for /phabricator, /libphutil and /phabricator as well as for the preceding parent-directory had to be 755.

Until i figured this out i tried running all directories with less permissions (750) - which did result in a

AuthorizedKeysCommand /usr/share/phabricator-ssh-hook.sh returned status 126

I really don't know which user is here trying to invoke whichever script or command (since all defined users [git, phd, www-data] are nicely coupled in their phacility-group), but since i wasn't able to track that down i think that's a good compromise. And it should be safer than letting root invoke the AuthorizedKeysCommand.

In T12856#231964, @pouyana wrote:

I wrote a small dynamic inventory client (based on almanac /passphrase conduit API). It is not open source but I can open source it, if there is a need.

A very rough version of this is now in master, but only active if phabricator.show-prototypes is on. These are some of the (substantial) remaining issues I'm aware of, and there are probably others:

I'm going to call this tentatively done and leave it open for a week or two to see if there's any fallout.

Something is making a lot of requests

I'm getting the same #1048: Column 'filename' cannot be null running just regular "arc diff". It used to work and then at some point after updates started failing.

The behavior of mod_reqtimeout is weird in production. Some of this is the LB, but some of it I don't have a good explanation for.

The above did not work for me. The following did:

I was able to get web001 to wedge a lot of requests in "R" ("Reading Request") -- note "SS" is "seconds since beginning of most recent request".

I'm also unable to wedge secure. mod_status is working there, but since I can't wedge it it isn't very useful.

I'm going to take a more detailed look at local behavior for this specific request pattern.

This is working somewhat better than before, but I'm still able to wedge apache with enough requests using a pre-patch version of libphutil. I'm going to take a more detailed look at local behavior for this specific request pattern.

It's currently possible for cluster hosts to hit rate limits against admin while doing normal deployment stuff, since they may make a lot of requests to admin very quickly.