Updated Docs and Website Automation Trigger + Procedures

[NightOwl888]

• You've read the Contributor Guide and Code of Conduct.
• You've included unit or integration tests for your change, where applicable.
• You've included inline docs for your change, where applicable.
• There's an open issue for the PR that you are making. If you'd like to propose a change, please open an issue to discuss the change or find an existing issue.

Updated Docs and Website Automation Trigger + Procedures

Description

This updates the automation for both the docs and website. Ever since the automation has been put in place, it has had to be executed manually. This update fixes the triggers so the automation happens automatically.

Website

The trigger was updated to make the master branch the source of truth for the website. This makes it simpler to manage because any PRs that are submitted to the master branch will be built into a PR on the lucenenet-site repo. Once merged, the changes go live.

Docs

The source of truth for any docs release is its corresponding docs/<version> branch. To update the docs, the updates must either be committed to the docs branch directly and merged to master or committed to master and cherry-picked onto the docs branch(es). The latter approach is generally more flexible.

This updates the trigger to fire automatically when any push is made to the docs/<version> site that will automatically build the docs site and submit a PR to the lucenenet-repo. Once merged, the changes go live.

Docs branches still must be created manually from a release branch, but once pushed, the automation kicks in.

NOTE: At some point we will probably want to build the docs from the release branch, but we will need to be consistent with our release branch naming and also there will need to be some sort of hold put on the docs build until the release branch is tagged.

This also corrects the logic so the branch names are uniquely identified by the incoming commit hash so multiple releases can be done on the same docs version.

Procedures

This updates the documentation.md file with a new section for both the docs and website which explain the source of truth for each site, workflows for updating the branches, and outlines some guidelines for how to move changes between branches to update both sites while also working with releases.

[jbampton]

From the https://pre-commit.com site

"Git hook scripts are useful for identifying simple issues before submission to code review. We run our hooks on every commit to automatically point out issues in code such as missing semicolons, trailing whitespace, and debug statements. By pointing these issues out before code review, this allows a code reviewer to focus on the architecture of a change while not wasting time with trivial style nitpicks."

The pre-commit tests failed for trailing whitespace and typos.

@NightOwl888 would you like me to add some documentation on how to install and run prek ?

[NightOwl888]

There is still a problem with how it creates the PR that I am tracking down. The first build didn't drop the docs files into the api/ folder and instead put all of its subfolders at the root. I confirmed it doesn't happen on the second run, so it appears to be happening because the directory doesn't exist which messes up Powershell's copy.