Separate Site and Controller repositories

[squeedee]

Description of problem

1. Site content changes at a different rate than the code
2. We often need to update versioned docs separate from the tag for that version (site is always built from a single branch, namely main)
3. Waiting for code checks on PRs when the only thing we've changed is documentation, is a significant pain
4. If we do end up creating a multi-product site (Eg, introduce runnable as it's own project) then we'll be out ahead of the infra changes needed (namely, seperating the Site repo :D)

Plan:

• create cartographer-site repo DONE

• Place all migration work on a branch initial-migration

  • ensure all branches for site work is merged
  • Move experimental editor over and patch the release code
  • Deal with the CRD generation code so it bases itself off the latest release in the cartographer repository
  • call for a moratorium on site PRs (explain why) in Slack, and put a [Blocked on Migration] tag on all related doc stories.
  • Ensure Linter runs in github actions
  • Ensure dependabot is configured
  • Configure require PR approval

• Make PR for initial-migration and get it merged

• prepare cartographer PR:

  • Clean up any call-through makefile targets in the cartographer makefile (they will no longer be able to reach the site) (dont merge!)
  • remove site and experimental live-editor from cartographer repo (Don't merge!)

• Have netlify use the new repository

• Merge cartographer PR

• unblock stories and let Slack know that the migration is complete

[scothis]

An intermediate option between same branch and different repos is to move website publishing to the gh-pages branch. It does mean that PRs need to be more considerate about which branch is the base.

[squeedee]

An intermediate option between same branch and different repos is to move website publishing to the gh-pages branch. It does mean that PRs need to be more considerate about which branch is the base.

Do you propose this because of the pain of obtaining another repository? Otherwise it's pretty slight for me - in fact I'd prefer the separation of concerns and the effort involved over the weirdness of a branch.

Would love for these steps to also help ease the plan, up front, for adopting other subsystems.

[scothis]

Do you propose this because of the pain of obtaining another repository?

Nope, getting a new repo should be easy. Multi-repo vs mono-repo is always a balancing act

[squeedee]

My feeling is that adding conditionals to GH actions to separate PR testing is ugly and a maintenance concern. So is the aforementioned PR targets. When we (I think inevitably) have maintenance branches for the binary, updating `site/docs/v#.#.#` on one branch to match changes to the branch/ `v#.#.#-main` (or even `main`) seems more cumbersome than 2 repos. I realize people can practice taking two checkouts, but still unwieldy IMHO. This feels like the right degree of separation, but happy to hear counterpoint.

…

On Tue, Dec 7, 2021 at 6:32 PM Scott Andrews ***@***.***> wrote: Do you propose this because of the pain of obtaining another repository? Nope, getting a new repo should be easy. Multi-repo vs mono-repo is always a balancing act — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#436 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAGZPXH6HLYZ53WDNVI3CTUP2KPXANCNFSM5JRXNJTQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[scothis]

There are no conditionals required for actions. Since the workflows are defined in source, you can have different workflows in different branches for pushes/prs.

[squeedee]

Which implies an intentionally different structure of the content of the branch (I'd rip out all the code) at which point, what benefit the branch over a new repo with clear concerns?

[martyspiewak]

I moved the last task for removing patch versions from the docs dropdown to a new issue in the cartographer-site repo: vmware-tanzu/cartographer-site#20

Closing this as It looks like the rest of the tasks have been completed.