Remove documentation site and GitHub Action, update README references

[ADubhlaoich]

Proposed changes

As of late December, NGINX has open sourced its documentation repository. The next stage of this effort is to consolidate all of the existing documentation into the single repository.

This commit removes the entire /site folder that was being used to manage the documentation for NGINX Gateway Fabric separately from the main pipeline, as well as the GitHub action used for deployment.

It also updates references to the folder to instead point towards the documentation repository, where all updates will be made in the future.

Paired with nginx/documentation#81

Checklist

Before creating a PR, run through this checklist and mark each as complete.

• I have read the CONTRIBUTING doc
• I have added tests that prove my fix is effective or that my feature works
• I have checked that all unit tests pass after adding my changes
• I have updated necessary documentation
• I have rebased my branch onto main
• I will ensure my PR is targeting the main branch and pulling from my branch from my own fork

Release notes

If this PR introduces a change that affects users and needs to be mentioned in the release notes,
please add a brief note that summarizes the change.

Migrated the documentation website into the NGINX documentation repository.

[ADubhlaoich]

Throwing this up as a draft to ensure nobody fires the gun on this early - the main repository PR to migrate this content hasn't been merged, and I will not put this out of draft until then.

[ADubhlaoich]

The migration has occurred in the main documentation repository: we're testing the deployment in development and staging before trying production.

[sjberman]

https://github.com/nginx/nginx-gateway-fabric/blob/main/site/content/reference/api.md is currently an autogenerated file based on some Go code in this repo, using this command.

Not sure how we're going to sync this with the docs repo.

[ADubhlaoich]

@sjberman For the time being it looks like it might have to be a manual move: I don't mind taking responsibility for it when it needs to happen.

@nginx-jack Tagging you for visibility since "solving" generated documentation for single sources of truth is one of the engineering buckets.

[sjberman]

@ADubhlaoich some sort of automation will be key, because it's inevitable that a developer will change the Go API in our repo, and forget to update the docs to match that. For now we can ensure it's a manual process, but that should be short term if possible.

The benefit we have with it living in our repo is our pipeline will fail if the doc isn't updated when it needs to be.

[sjberman]

This site/config/api directory needs to remain in some capacity because it's used to autogenerate our API reference doc. If moved, then the Makefile target generate-api-docs should reference the new location of the config.

[ADubhlaoich]

I think it'll be somewhat odd to have an otherwise empty folder left for the API reference document: I'll examine the Makefile target and think of a higher-level folder to keep it in.

[sjberman]

https://github.com/nginx/nginx-gateway-fabric/blob/main/docs/developer/release-process.md also needs to be updated for whatever the new docs process will be. Specifically step 8.

Something to do with merging docs into main in the docs repo, and then creating a branch for our next release for unreleased docs.

[sjberman]

Shoot, I also just realized we have a whole automation setup that updates our docs with new version info before a release. None of that automation is going to work now that we're migrating. This will also now have to be a manual process added to the release process doc to occur before the release.

https://github.com/nginx/nginx-gateway-fabric/blob/main/.github/workflows/release-pr.yml

[ADubhlaoich]

Shoot, I also just realized we have a whole automation setup that updates our docs with new version info before a release. None of that automation is going to work now that we're migrating. This will also now have to be a manual process added to the release process doc to occur before the release.

https://github.com/nginx/nginx-gateway-fabric/blob/main/.github/workflows/release-pr.yml

@nginx-jack , something to look at - NGINX Ingress Controller also has some release version automation.

NGINX Ingress Controller actually uses a Hugo shortcode as a sort of pseudo-variable to simplify version updates for documentation: might be a pattern worth adopting?

[nginx-jack]

One option would be to update this action to clone the documentation repo, and perform the same steps against content/ngf/, and create a PR against the documentation repo.
Also, is this process useful for other projects? Ideally we can follow the same documentation release process for all the OSS projects 🤞 .

[sjberman]

In the meantime the find and replace step in that action for the site/ folder can be removed as part of this PR