I think this (and lint/coverage) should move to Conduit, yeah.

Cool, now I don't feel so bad since I know you only recently added the option 😄

(That said, my expectation is that behaviors around unreachable commits have not changed -- D17279 added the "Unreachable" option to solve this problem.)

Likely somewhere in T9430 / T10978, which rewrote a big chunk of the audit code.

That works, Im curious when this changed, as I didn't need to filter since the last few weeks.

If you don't want to see unreachable commits, use a query which hides them:

The reason I think something isn't working correctly is in my dashboard, I list recent commits, and since I updated my install a few weeks ago my commit list looks like this a lot:

It is expected that some deleted commits will import and others will not.

See T12298#213181.

Thanks @epriestley and @rfreebern - your scripts worked perfectly! Between them both (and tweaking that one "hasSubprojects" field in the database myself), I was able to move an entire project tree. Yay!

@epriestley all other commits that have the message "This commit has been deleted in the repository: it is no longer reachable from any branch, tag, or ref." have imported, so I don't think the reachable code is working correctly, as until within the last few weeks I wasn't seeing these "This commit has been deleted in the repository: it is no longer reachable from any branch, tag, or ref." commits showing up, but now I see them all the time.

For the record, you can work around the problem as such:

{
  "linters": {
    "filename": {
      "type": "filename",
      "exclude": ["(\\+)", "(\\@)"]
    }
}

Total cost is about 1.6s. Of this:

This is still a little bit of a pain but far more reasonable now, here's an actual profile:

I cycled the rest of the tier and things look better now.

After manually deploying that to repo001, I'm now seeing a consistent Taskmaster/PullLocal count. I'm redeploying the rest of the repo hosts.

I think the issue is that the --reserve flag for reserving system memory now applies to even the first daemon in a pool, because all daemons are now part of pools. Previously, it only applied only to the 2nd..Nth daemon.

Some taskmasters failed to start on repo001 and perhaps elsewhere.

I suspended and destroyed the largest instance on the shard, a free instance with one user and no logins for >30 days (the user appears to have imported a huge repository and then never logged back in). We still have backups, but this instance was way over reasonable resource use anyway. The volume is now 78% full.

I pruned some very old backups (backup pruning is currently very conservative in several cases). The volume is now 72% full. This could easily be reduced much further by allowing bin/host prune to remove backups older than 90 days for suspended/terminated instances that have been out of service for 90 days, but backup utilization is generally relatively stable so I'm not concerned about this.

I synchronized services for this shard and destroyed old instances. The volume is now 68% full.

I synchronized services for this shard and destroyed old instances. The volume is now 44% full.

This was a bunch of repository file data in /tmp. Each file was unique, so this doesn't look like any sort of buggy loop or anything. There's some actual bug here but since there's a long list of other issues here I just "fixed" this by clearing /tmp.

Some reserved instances ended on Feb 19th; I should make sure reserved instances match production instances.

Shards 017 through 020 are now in production.

We would be prepared to step in for prioritization on this.

The re-launched hosts seem OK, I'm waiting for DNS to update and then redeploying them.

The hosts launched into an "Auto-Assign Public IPv4" subnet but didn't get IPv4 addresses. Restarting them didn't help, and there's no apparent way to assign public addresses after the fact. I'm going to throw them away and try again.

I'm going to put more hosts into production immediately before pursuing other issues.

• Some reserved instances ended on Feb 19th; I should make sure reserved instances match production instances.

• The tier as a whole is 88% full.

So here's a tentative plan for subtyping:

Custom Forms are the general tool we want to use here, but they currently have some limitations for this use case. As a starting point, here's what they can do today, some of the strengths, and some of the weaknesses.

@epriestley Yep - like what you're doing there :)

So I don't forget:

Maybe the "Install Arcanist" header on Quick Start could be like:

Oh, no, it's just to do with the ordering of the links vs the annotations: if you're totally new to phabricator, you're going to get tripped on the "quick start" link which says "install stuff" and in the middle links you back two pages...

I'm assuming he wants us to duplicate the installation information onto Win/Mac pages or only link to those pages after installing arcanist.

That is, this passage:

There's a short version and a long version. Each version links to the other version, saying "here's a different version of these instructions, if you'd prefer that one". How could we make this more clear?

Thanks! I guess nobody ever noticed that before!

Just a note for the above - the initial DB seed script will need to be updated accordingly as well. Right now, trying to perform a clean install on a 2nd-gen Google Cloud SQL instance (which has the above limitation) simply errors out when it reaches one of the tables coded as MyISAM.

@pouyana Here's a workaround for you. In your notification.servers Phabricator configuration, add path: "/ws/" to the client server. Then, modify your apache configuration like so:

I don't see how to configure/use that

Neither can I - I may have imagined it being possible to "lock" the edit form of a task to the one that was used to create them...

I think it's fine to disallow changing from one type to another - can that be enforced? And sure, I think the custom form approach would work but I don't see how to configure/use that - can you point me in the right direction? I presume this implies that the underlying fields are the union of those exposed by all of the forms which would be fine.

This is a followup to a private discussion elsewhere, I'll flesh it out a bit when I have a chance.

Can a task mutate between "feature" and "risk"? If not, can you use a different Custom Form for each type, which will hide the unused fields?

The commit cache should be a fairly large performance win.

Hibernating daemons currently show as "Waiting" in the Daemon console, but I'm not going to worry about that for now.

Ah, okay. This is the relevant part:

@epriestley
https://test-3uoifmrptebb.phacility.com/R2:80233a27d7b72bb03710d358e12a531ce46808a9

good luck w/ teeth 😁

Starting with repository update:

so excite. much radiation.

Broadly, there is nothing Phabricator could have done differently to anticipate or prevent this issue.

We could also provide some kind of bin/auth burn-everything-to-the-ground to automate these steps, but I worry that it would almost never be tested (I think it's very difficult to test comprehensively in an automated way) or run, and there's a good chance it might be forgotten about when authentication changes occur.

Ah, you're right. It looks like request data may also have leaked. I'll edit my earlier posts to reflect that. Briefly, the change is: passwords and VCS passwords are potentially at risk.

Has cloudflare explicitly said that only responses were leaked, and never
requests? I recall "POST data" being explicitly called out as showing up in
the leaks, but I can't remember if this was in an official write up or
media coverage.

To cycle passwords, you can do this:

Only our websocket host is behind CF proxies, so I invalidated all auth sessions by changing the security.hmac-key. I wanted to also invalidate all Conduit tokens just as a fire drill but couldn't found a method of doing this.

My impression is that there is a lot of room for optimization in the RepositoryPullLocalDaemon. I've wanted to tackle that for a while because it causes a fair delay between when a commit goes into git and when it actually shows up in Diffusion.

I found that svn repo import was stuck on a very large branch import. I marked the repo as imported, suddenly the herald rules and notifications started to work properly (which was my other problem that I wanted to solve with my instance).

Hello I have a question that:
if there are several users written in comments in Pholio Mocks part, how can I see other person's comments?

If you have configured your entire install behind Cloudflare (we do not encourage this in the documentation), you are at greater risk, as anything served by Phabricator could have been leaked. If you believe you are affected and would like help rotating sessions and invalidating credentials, let us know.

Events stuff isn't on any roadmap, so it also could be years before it was modified.