You don't need any plugins with staging. Just set up a parameterised build, use a parameter for the commit and call directly from harbormaster. That's reason for staging repos, regular git tooling can work with them.

The logs themselves are a bug that's been around for a while, but I think they're from a race condition that I believed only caused things to log messages with no ill effects.

Hmm, this is pretty interesting. There was a configuration change right at the time of impact:

I see, it makes sense now that I know what's going on. Not sure if there's a better way to write it honestly.

Here's the section that's intended to explain it. This applies to Mercurial, too (in theory) which is why we don't explicitly mention git fetch.

Got it, thanks!

@chad, I've updated the title to reflect the updated (and confirmed) duplication instructions. The specific problem is that, if a project has subprojects, then any milestones belonging to the base project cannot be modified.

The staging repository allows you to git fetch the change to the build server (which is easier and more reliable), instead of using arc patch.

The diagnostically useful information from the trace is that this:

In https://<your.install.com>/config/history/, is there a configuration change of any kind shortly before 17:19 UTC?

I see. The rule you showed was actually exactly how I set this up before adding a staging repo.

(Per T10799, T6878 is the underlying issue with why they don't import, but it's currently never materially useful to import them so this hasn't been a priority to fix. Empirically, they do not import on this install but builds work fine -- except see also T10667 for a weird special case mostly unique to this install.)

Staging is required (well, not strictly required, but strongly recommended) to setup CI.

Thanks for the reply. I may be confused then. Based on the Harbormaster documentation I understood that staging was required to setup CI. Please correct me if I'm wrong. This is my first time setting this up.

I am not sure exactly what you are trying to achieve, but if you want to do CI with differentials, just set up a herald rule to trigger a build plan when a diff is created / updated. This will trigger whether the staging commits are imported by phabricator or not.

Since the commit is not imported, I believe this is currently preventing me from setting up CI with Herald/Harbormaster/Jenkins.

I can not reproduce this issue by following your reproduction steps. Here's what I see on this install:

I can confirm this is fixed now.
Thanks, @vinzent @epriestley , for this ultra quick fix!

I've marked D15705 as fixing this, since it makes our interpretation of the path unambiguous: we would no longer interpret /ws/ as a request for namespace "ws".

@epriestley Thanks for the quick fix!

Sorry about breaking this -- there are a lot of large changes going in this week related to T10751, so master might be a little less stable than usual until the dust settles there.

just updated, it works now without cluster.addresses set.

This should now be fixed in HEAD.

This report does not include reproduction steps. See Providing Reproduction Steps for help.

Upgrade Phabricator. This is fixed in HEAD.

Error if cluster.addresses is not set at all:

D11159 seems to be related

Not a solution, but a workaround until fix:
Revert the repository temporarily to abf37aa9794790fbc0e215102519e9ffc7e99b7e.

Temporarily checked out abf37aa9794790fbc0e215102519e9ffc7e99b7e; Phabricator is accessable again.

Related: T10801

git

git, svn, or hg?

To remove one variable, I experienced the same issue if both repos were locally hosted on phabricator. I tried updating just before posting this bug report. The commit I have (from stable branch) is 5ddaf5289862cce3957c5630eb11df31fb0786b8.

Please fill in the rest of the information required on bug reports please, version and clear steps to reproduce. Thanks!

This should be fixed in HEAD of master. Thanks for the report, let us know if you run into anything else.

Fantastic, applied locally and it works as intended. Thank you! 👍

Not 100% sure that's a fix, but I was able to reproduce something that looked similar and that appeared to fix it locally.

Awesome, thanks 👍

You can put lines=30 or similar after the triple backticks in the header:

Here it is (not sure if I caught everything that I might need to censor, please let me know if I missed anything):

(You may need to censor Authorization header bodies.)

What does GIT_CURL_VERBOSE=1 GIT_TRACE=1 look like for GitHub in your environment?

Since Windows tends to languish near the bottom of the priority list and I'm fairly confident this patch is fine, I'll accept it upstream if you use it for a couple days and nothing explodes and want to submit it.

I suspect that fix is safe and correct. It would be nice to kick the tires a little more before applying it and maybe try to dream up some test coverage, but it shouldn't have broader implications within the arc ecosystem.

Today the live notifications work in Firefox as well. I believe that it did not work yesterday due to caching.

I used gmail app. I was using inline quoting, hoping to have a result similar to the web "quote" function.
The tests you mention don't include any inline quotation, and a little browsing Maniphest leads me to T5181: Parse in-line replies in email responses .

This should be resolved at HEAD of master; updating Phabricator should restore things to working order.

I happen to know this one offhand.

Quoting and signature stripping works properly in major clients -- you can find the implementation here:

Ha. I see quoting via email doesnt work properly

(via edit or follow up comment). We also have plenty of valid reasons
someone wants to post just a quote (especially on long threads). I can't
see much value in spending engineering time on this, personally.

I would generally assume most people quote without text intentionally, more so than accidentally. At least anecdotally I quote things without comment and I don't recall doing it by accident. If it something with page loads, we could maybe take a look into that specifically.

Basically I think this occurs very rarely, is immediately recoverable (via edit or follow up comment). We also have plenty of valid reasons someone wants to post just a quote (especially on long threads). I can't see much value in spending engineering time on this, personally.

I consider this expected.

I believe D15612 introduced the bug, but unclear why newDialog isn't doing the right thing here overall. Easy to revert.

This bug report is missing complete steps to reproduce as well as version information.