You can do this by referencing the commit it fixes in the commit message. Like:

And also, we may want reviewer to see the comment easily, not by open two audit requests at same time. I just want to make the process smoothly, how do you think?

I agree it should be re-reviewed.

You should be doing pre-commit reviews, if that is the workflow you desire. That way if errors are found in code, they are fixed before they land in the repository. We have no means if you're only doing code audits, of knowing if one commit is just a fix for another commit (which, even if it is, should be re-reviewed).

I'm going to merge this into T5873, which discusses expanding Conduit to improve support for the "Edge" infrastructure. This includes subscriptions.

Yep, I can confirm the fix seems to work correctly. Thanks.

Closed by commit rPac4247ea59eb.

@epriestley, understood. We have consensus about the importance of gadgets in the MediaWiki context (they are important), but we don't have consensus about the best way to organize code review for them, since the development process is currently very light compared to the development of MediaWiki core and extensions, with Git, CI, and all. Using Phabricator is one of the options we have on the table, and it is not even the current forerunner (partially thanks to your feedback).

Or, put another way, I estimate the cost of this feature is far greater than all other features WMF has ever asked for combined, and that it's also near the bottom of the list in terms of utility to other installs and overlap with the "natural" upstream roadmap. This makes it very hard for us to get excited about, and if we did prioritize it it would be at the cost of everything else.

My general concern here is that I want to focus our efforts on building the most valuable features. I don't want to spend a lot of time and effort building something which isn't very useful and takes a long time to build when we could be building something more useful that's easier to build instead.

@epriestley: In Wikimedia's case (AFAIUI), tests & Co. are run by Jenkins, so that's not an inability to run them. For example, with the existing Gerrit instance, web edits of the commit message trigger new Jenkins runs. (NB: I didn't searched too much what Drydock and Releeph are, but they don't seem to take over Jenkins' role.)

Closed by commit rPa6296a64a457.

I believe D10414 will resolve this. After it lands, edit the credential, delete any bullets in the "password" field, and save it. Then "Reveal Secret" should show an explicit "empty" message, and it should work for authentication.

We might already be doing this, but we could make the state viewer-dependent. Instead of "Audited" vs "Partially Audited" vs "Audit Required", we could show "Audited", "Audit Required by Others" and "Audit Required by You" (with shorter names, maybe). For your commits, this would need to be a bit different.

There's a long discussion on this off-ticket, but the summary is:

Closed by commit rP2f4addc67113.

Closed by commit rP7ecbc707846f.

I think *this* Phabricator install has the most junk in it of any install on the planet. Easily top 10 if not #1... :D

I can confirm this issue.

◀ Merged tasks: T6025.

Right now I'm not sure there's any distinction between audits triggered by global rules, and audits triggered by personal rules. That means if anyone sets up a personal Herald rule to trigger an audit, it will cause Diffusion to only show "Partially Audited" (if that person doesn't respond). This is the case on this Phabricator install, where every commit without a review is affected by a personal rule that someone has set up.

◀ Merged tasks: T6022.

◀ Merged tasks: T6021.

✘ Merged into T3498.

I think it caused by some editor difference.

can we ignore this by such setting just like ignore whitespace

The line ending of every line was changed from \r\n to \n, which is why the whole file appears to be changed.

Attached:

Or the raw git diff or whatever?

Can you attach the old and new files to this task?

Thanks @aik099 for all the help. The code did have yet another bug in it, which I think D10386 resolves. Post D10386 someone in this situation should get a warning to try again with sudo, and then using sudo should actually work.

Ah okay, I found the code bug here. Patch in a little...

We should probably create the Secret, just leave the secret plaintext empty. We probably just didn't think about this case when writing the code, as it's a little unusual.

✘ Merged into T5698.

✘ Merged into T5956.

I've found the problem. It appears that there are 10 rouge daemons and one was detected at a time. I've killed all "php" processed executed by Phabricator using "sudo" and now problem is gone. Several restarts never cause rouge daemons to appear.

Here is the output of sudo ./bin/phd stop --force:

Ah sorry, it sounded like the issue was still open - didn't want to lose track.

@chad - did you hear of other reports or something?

can you give me the latest output from running ./bin/phd restart --force and ./bin/phd restart ?

Closed by commit rPd1936711a077.

It would be really helpful to see the actual output from running those two commands back to back.

Yes. No change.

can you give me the latest output from running ./bin/phd restart --force and ./bin/phd restart ?

Yes. I'm using update_phabricator.sh script from documentation.

You updated libphutil when you updated, yes? rPHUae43ce54f61f200028b44f2400ca68008e297f60 is needed too.

It got worse in fact. Now I have 2 of daemons ported as hanging.

Okay thanks. There was a bug that I think rP2fdd7f0f3d2e316a15bf7a903b7c963b04290af8. Once you update let us know if this persists. :) Closing for now in optimistic spirits.

Nope. Just reported what I saw. Since I only had this problem on 1 of 2 Phabricator installs I thought this might be something to do with configuration.

Are you seeing this post rP2fdd7f0f3d2e316a15bf7a903b7c963b04290af8 ?

◀ Merged tasks: T5935.

✘ Merged into T2999.

anyone is checking this ?

I'm getting the same error as OP. It looks like the folder for the created repo is owned by root with drwxr-xr-x. If I chown the folder to my phd user, I can push to the repo.

Awesome! Let us know if you run into anything else.

Well, we just figured out the issues with SSH, and I have now pushed this entire repo. Thanks for working on Phabricator!

The rule should identify closed revisions:

Sure, I can try to help you set things up.

It does, but the revision is already in a closed status, so it doesn't count when performing the rule (or at least it didn't when we started using it). The exact sequence is something like this:

Thanks for fast response! Unfortunately, we haven't been able to SSH to work either - seems like an auth problem currently. Should I create an issue describing our problems there?

✘ Merged into T4369.

◀ Merged tasks: T5961.

HTTP has pretty severe scalability limits right now. The only real workaround is to use SSH instead.

See T4778 for discussion of how we prioritize.

Old task (1+ year old). Maybe this can be implemented in visible future (e.g. before end of the year)?

✘ Merged into T3498.

◀ Merged tasks: T5959.

Aaah, okay.

Maybe there is such option in the Differential, but not in Diffusion, where I'm looking at commit and writing audit on it.