Also need to allow fake 'Home' to be hidden... somehow. I can make a fallback page if needed.

It looks like it works, it's just a little confusing since "Home" doesn't show up. I'll fix that:

Also, we might be torpedoing open-source installs which don't have a dashboard right now since the magic "Home" doesn't show up if you're logged out. I'll look at that.

I think that's a whole pile of work, I was just thinking that administrators could disable the global item.

I looked briefly, but couldn't figure out how to move fake 'Home' into the Personal Menu as a built-in

Leave the default fake 'Home' as is (corporate install, your stuff)

Based on that, the problem to solve is making "contributor" type dashboards easy to find/install.

So let me walk through what I think you're suggesting.

I also, generally, can't come up with any uses for links that or other items which are only visible after you log in, outside of dashboards.

I'd like to wait until we have a good answer on how we'd use this feature before we pursue it. I worry that it adds a significant amount of complexity and may really have zero use cases. In the best case, it is useful to only a tiny number of open source installs.

As far as Dashboards in general go, I was planning on that next (as a project to clean up) and haven't given a lot of thought about logged in / logged out versions. I have no idea how many installs rely on these, so assumed at least, we weren't removing the feature.

As a user, being able to hide global links is probably going to come up, and is another way to resolve this.

Oh, or is that non-hypothetical?

You're asking me a question I'd probably put a few weeks in to answer.

How would you like the two dashboards to differ on this install?

The main thing right now is we have two different Home dashboards. If there was a way to resolve that to just one (maybe I just do this in PhabricatorHomeMenuItem?) then we shouldn't need public/all user menu items. At least, I'd wait for more use cases like you suggest.

Oh, maybe I misunderstood then. How would you like to make the logged-out vs logged-in menus different on this install, or how do you think other open source installs would benefit from this? (This only impacts open-source installs, right?)

I was referring to menu items. If we can fix up Dashboards enough that (logged in/logged out) is a single dashboard, I think that resolves the immediate use case.

I'm not really sold on the use case -- which is just letting open source installs have a logged-in dashboard tailored to the user, right?

Are we comfortable for Global menus of giving admins "visible (logged in), visible (logged out), visible (all), and hidden" as visibility options? Or just implement Policy and really confuse everything?

Please follow the rules in Contributing Feature Requests when submitting feature requests.

T6143, while closed, seems to be a real-world use case to me.

• After D17282, we do branch=phabricator/diff/689, commit=HEAD when building revisions.
• After D17282, we do branch=<one arbitrary containing branch>, commit=<commit hash> when building commits.
• The "GitHub Settings" workaround above resolved the "tags disabled" issue, as suggested.

Yeah, run bin/audit synchronize --all (or rXYZ for just one repository) after doing manual cleanup with bin/audit delete. This is noted in the documentation at HEAD as of ~yesterday, although it may not have regenerated in production yet.

I've made some progress in the direction of this task in D16981 and D17020, but I've since then more-or-less lost the external pressure to implement this. I might get around to completing this eventually, but I might not.
The code in those diffs is mostly usable, but it does require some amount of local extensions to be implemented. If anyone is interested in trying it out (Or even taking over the changes), I can instruct you on how to do it locally and what's missing.

Realized this is probably solved by rPaca0f642a3bdaa602bde05abfe94f9d90cf7b06e. Will switch to master.

In T10215#197801, @epriestley wrote:

We can also let installs send us all their data, we'll decide if it's spam or not, then we remotely delete any data that we feel like deleting. But we'd have to charge like a gorillion dollars per message to make this sustainable today.

Almanac's is a bit tight too

Using {"branch": "phabricator/diff/689", "commit": "HEAD", "message": "..."} should roughly translate into a git fetch phabricator/diff/689 && git checkout FETCH_HEAD in the Buildkite agent bootstrap script. Git is smart enough to resolve that to the tag. The branch name is really only used in Buildkite for branch filters, on the agent Git does a headless checkout. And a commit value of HEAD means we'll ask Git for the commit sha and back-populate that onto the build. 👍

I think I've pushed this approximately as far as I plan to in this iteration. Everything mentioned in the description has been tackled, and audits on this install are now in a relatively sane state.

(arc list will also grow some kind of --reviewer=me --status=open mode in T7715, but I suspect that no one would really care if arc patch just did that by default.)

In T12027#209445, @epriestley wrote:

D17283 allows you to double-click the D1234 crumb to select it, since it's no longer a link. I don't know if double-clicks are too complicated or not.

D17283 allows you to double-click the D1234 crumb to select it, since it's no longer a link. I don't know if double-clicks are too complicated or not.

Some users really do not like command line. Like really. 😂

Just for my own clarification: these are technical users using Git to review changes to code, who don't enable "Full website address" and don't like the command line?

The selection junk is caused by float: left which apparently fixed some kind of IE thing in 2014 (T5902) so that may be involved to fix.

Also a lot of users do not notice this text is in the URL since on Safari the browser hides everything except the domain until you click on it.

One general improvement we could make is to have arc patch without arguments offer you open, non-authored revisions in the same repository, using the new numerical menu selector from T10895. That might moot this, and I can't immediately imagine any other default behaviors for arc patch with no arguments (other than showing you how to provide arguments, as it currently does, but we could retain this text in an abbreviated form).

This text is larger than the old arc patch text was, isn't it? It's also copyable from the URL bar. And surely text from a hypothetical arc list-stuff-I-am-reviewing isn't any easier to copy/paste than this text?

One general improvement we could make is to have arc patch without arguments offer you open, non-authored revisions in the same repository, using the new numerical menu selector from T10895. That might moot this, and I can't immediately imagine any other default behaviors for arc patch with no arguments (other than showing you how to provide arguments, as it currently does, but we could retain this text in an abbreviated form).

I'm also confused about this:

my bad for wrong merge

arc <list of diffs I need to review>

arc list will eventually be more flexible (T7715) but today it's only your stuff.

Moving over comment from T12179

Er, oh, other reviews. Then maybe this feedback should be on T12026, rather than here.

That's just your stuff?

Oh, then arc list?

I assume he means other peoples reviews that are out

@jcarrillo7: there is no command line way to get back a list of reviews (with their identifiers) that are active for the current repo.

@chad yeah sorry for the noise I will go ahead and move it as a comment over there.

Probably best to have all threads in one task, go ahead and comment on T12027 directly. Thanks!

We queried a subset of instances to gain insight about how frequently repository data is hosted on GitLab, so we're better prepared to respond to any indirect fallout from a recent operational incident on their side:

🤔

Broadly, I'm supportive.

All changes in Phabricator need to be driven by strong, real-world use-cases.

@epriestley I hope to fix this in a very general way, which will also solve many of the other tickets related to Remarkup (T6276, T5951, T5427).

Resolved at HEAD. Follow T12174 for bugs/feature requests/future action items.

So, @epriestley: How do you feel about me taking over elasticsearch backend and moving it out to an extension rather than keeping it in phabricator core? The other possibility is I could just fork the elastic backend and name it something different, as it seems phabricator already supports loading the engine extension dynamically.

@ramm: I'm already on it: https://phabricator.wikimedia.org/T155299

In T9530#177353, @hach-que wrote:

So I was thinking about software components recently and one of the issues I've had with both Jenkins and Harbormaster is that builds of one repository aren't aware of the builds from another repository. This is a common scenario in the software I build:

I'd like to see real use cases for this before pursuing it. In the use cases above:

Oh! I think you found a bug. If you go to "GitHub Settings" on that page, enable "Trigger builds after pushing code", then enable "Build tags", then save. Then switch back to "Disable GitHub triggered builds", then save, it should hopefully start working for you.

Build also works fine if I submit it unmodified but omit the refs/tags/... prefix.

Only hit for "tag" is in this paragraph, which has no limits set (unless "empty text field" means "no tags"):

Here's a more granular transcript which suggests I'm not doing something goofy:

Check out your pipeline settings, if you "ctrl-f" for the word "tag" - is there an option somewhere?

When I submit this:

I'll take this and T6002. Where in Phabricator's source code can I find the relevant PHP code? Edit: Found it in libphutil.

Upshot: I'll do the thing that works for now. If we have tension down the road for the "code reviews intended for master" vs "code reviews intended for develop" use case, we can deal with it when it actually arises. It may be completely hypothetical. Users that did care could conceivably lift HARBORMASTER_BUILD_TARGET_PHID out of the environment and use Conduit to figure out where the review was targeted.

I guess there's also some amount of overloading here for "branch" and "commit", which is understandable since building tags/refs is rare.