OK, yes, that is the default "Builtin" one we ship with. It wasn't previously visible if you installed a global default. When you migrate to HEAD, it should have ended up with 2 links, one for the built-in home, and one for the global dashboard that was migrated. You can disable the builtin Home under Global Menu Item.

Before "Home Menu"

You'd need to tell me more about how your install was previously, in case we missed something with migration.

Ok. But I see two different "Home" Dashboards on our install. It is expected?

Theres a lot of flexibility here, so hollar if you get stuck trying to implement something.

You can now have multiple dashboards, and I think we'll default to the top-most.

I'll write up a blog post this week and I suspect we'll have a migration guide since it's new to old admins.

It's no longer a config, nor do you need to "Install Dashboard", Just add your new one to the sidenav and disable the built in.

Is there a way to change the default dashboard used for Home? Couldnt find a config for this.

I've been seeing exceptions about "Can't parse an empty diff" in daemon logs, which I believe happens occasionally when merging commits and using a strategy to ignore changes from the incoming commit. This happens when merging a branch which might contain commits with similar/same changes which should not be kept due to already being resolved upstream. This results in any phabricator revisions/audits always showing the "Loading Content" when viewing in web.

Usually every Saturday we cut stable, unless we're writing a lot of bugs that particular week.

This sounds great, thanks. We only plan to use it for testing Diffs at this time, so the other branch limitations aren't a concern right now.

We have 2 Homes, I'd like 1.

Why do we need to allow it to be hidden?

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:

🤔