Scope, name, domain, hosting

[hobofan]

As a few connected topics (scope, name, domain, hosting of this repo) still seems to be a point of discussion, and we seem to be going back and forth (and in circles) with it, I'll try to outline the major points and options in preparation for today's SIG meeting.

As I'm also trying to summarize stances that are not my own, I hope that I'm not misrepresenting anyone.

Scope

• Common agreement: The main scope of the website provided by the repository should be to help the Bazel community in the discovery of bzlmod modules contained in the BCR
• AFAIK the Bazel team would like the website to be focused on that scope quite closely and rather not contain any additional editorialized content (which is understandable to keep neutrality relative to the wider Bazel community)
• The SIG would possibly like to expand the scope of the website to also include information about rulesets that are not in the BCR (at least for the transition phase) and possibly some form of curation through the SIG based on quality signals (which will be hard/impossible to set up in a completely neutral way). There is also a higher perceived need to include GitHub-based (usage) data for rulesets on the website

One option to resolve the tension here would be to have two websites. One focused on data in the BCR, and one more focused on SIG catalog data.

Name (of the repository)

Names that have been floated:

• bazel-contrib/bcr-web-ui (current)
• bazel-contrib/bcr-ui
• bazel-contrib/bcr
• Possibly some other name that doesn't include "bcr", if we expand the scope significantly beyond the contents of the BCR

Domain

Main considerations for the domain:

• The domain should accurately reflect the contents of the website
• A stable domain name will help the website to spread, as people can put permalinks to the website into their ruleset repositories
• A .bazel.build domain would help the website spread as it signals close affiliation with the Bazel project

Options:

• bcr.bazel.build - This is already used for the bucket that is mirroring the BCR
• registry.bazel.build - Overall preferred domain by everyone, but comes with some hoops to jump through due to possible security implications
• Some variation of bazelbuild.github.io/bazel-central-registry
• Some variation of bazel-contrib.github.io/XYZ - Possibly more suitable if a lot of non-BCR content should be part of the website
• Some other custom domain name not under .bazel.build

Hosting & deployment

A new deployment should be triggered on any change of either the BCR contents or the source of the website (and possibly also on a cronjob if we include GitHub-based "scraped" data that should be up-to-date)

As that system is a non-trivial part of the project, it would be good to have flexibility in adjusting parts of the CI process that produces the static files for the website

Hosting options:

• A static site hoster like Netlify - Easy to deploy to, but especially in combination with registry.bazel.build not great, as it would opaquely involve an additional party (beyond Google and GitHub)
• GitHub pages - Okay-ish easy to deploy to, but non-trivial to intractable if we need to deploy to the gh-pages branch of another repository, especially if it's across organization boundaries and with full security considerations
• Google Cloud Storage (GCS) bucket - Okay-ish easy to deploy to (would need to be tested as some of us have experienced problems with it in the past when combined with a proper domain name). Has good options for scoping permissions only to that bucket, though.

CI/Deployment options:

• Github Actions (triggered via BCR GH Actions) - Status quo. Works well and is well documented
• Bazel CI trusted environment (= Buildkite?) - Would have permissions set up in a way that would allow to deploy to the GH Pages branch of bazelbuild/bazel-central-registry.

---

My personal opinions on all this:

• My optimal scenario would be
  • Scope: BCR contents + SIG catalog + scraped Github data
  • Domain: registry.bazel.build
  • Hosting: GCS bucket (needs testing, though)
  • CI: Github Actions
• I would prefer a "nice" looking domain name over other options (.github.io/XZY), be it registry.bazel.build or one we have yet to come up with
• I would very much like to avoid having two websites. I would like to avoid the additional maintenance, and I think it would also provide a worse experience for the community (one option to reduce this would be if we would cross-link between the two websites for the individual modules).
• As a relative new-comer what exactly Bazel CI, and especially the "trusted environment" is (Where does it run? What parts of it can do what? What's the security model?) seems quite hard to grok (which would make it hard to onboard new contributors to the repo). It also feels like transferring significant parts of the CI system there could take away needed flexibility (or would possibly violate the security model?)

[alexeagle]

We're quite constrained by the time we have available as well. I think we need to bias to something simple, and which doesn't require more from the Bazel team.

"nice" looking domain name over other options

Yes I'm sure we'll pick a nice domain name as a redirect, not use the Netlify/GH pages generated URL as the canonical one

like to avoid having two websites

Agreed, maybe we can make the scope for the first launch be "only data from BCR" and then discuss how to be objective and transparent as we add more data post-launch?

transferring significant parts of the CI system there could take away needed flexibility

I think this is key, we should be reducing the burden on the Bazel team by having bazel-contrib be community-maintained. I think anything that requires Googlers to train us on how Bazel CI is architected, or is blocked on Googlers making infra changes, we should avoid doing.

[hobofan]

The outcome of the SIG meeting today:

The planned setup for this repo is:

• Scope: BCR data only (as the Bazel team want to keep neutrality regarding the community)
• Hosting + domain: registry.bazel.build that will point to a GCP bucket that @meteorcloudy will setup
• Deployment: Github Actions of this repo will push to that GCP bucket via a service account key that has permissions only for that repository (key to be provided by @meteorcloudy). I'll take care of that setup in both repositories, as far as I can.
• Repo name: has been changed to bcr-ui after some bikeshedding 🙃

As this repo is already providing the main function the Bazel team was looking for of providing a "HTML-rendered version of the bzlmod contents", we should be good for launch on that front after the infrastructure setup.

---

To provide a venue where the SIG can include additional data about non-bzlmod rulesets and "do whatever we want", we will set up a separate website that will provide a superset of the functionality of this website. As I think some data we would display there could greatly help the ecosystem transition (see #11), I'll try to get started on that front ASAP so that can also go online soon.

[hobofan]

Closing this, as what needed to be decided has been decided (and implemented), and there aren't any more actionables for this repo left.

The open follow-up issue for this would be to create the SIG-only "catalog" fork of this.