Docs - automate the website updates when publishing new docs about lucenenet HOT 1 OPEN

It seems there are several different workflows to deal with here:

1. Update the website on https://github.com/apache/lucenenet-site/tree/asf-site when a change to the websites/site folder is committed to master
2. Update the docs and website when there is a new release (with a step to make a new docs link/TOC)
3. Update the docs on https://github.com/apache/lucenenet-site/tree/asf-site/docs/ <version> when there is a docs change committed to one of the docs/<version> branches
4. Create a temporary URL of the docs when a PR is submitted to any of the docs/<version> branches so the person who submits it can preview the docs
5. Create a temporary URL of the website when a PR is submitted so the person who submits it can preview the website
6. Create a temporary URL of the docs and website to be part of a release pipeline so it can be previewed during the release vote

Numbers 1 through 3 are higher priority than 4 through 6.

Due to the fact we cannot use Azure DevOps for PRs due to Apache permission limitations, we should use GitHub Actions for those tasks. It would also be pretty simple to setup GitHub actions to auto-deploy the website when master is updated. I recently used path filters on a GitHub Actions workflow to exclude paths that don't apply to the workflow, which would work perfectly for this scenario.

As for the temporary URLs, we could use the approach outlined in Static Web App PR Workflow for Azure App Service Using Azure DevOps. We can probably adapt the solution to launch from GitHub Actions rather than from Azure DevOps so the PRs will kick it off.

Notes:

1. GitHub Actions doesn't load workflow files with a . in the name
2. Apache has a limited number of build agents for GitHub Actions, so long-running tasks should be done in Azure DevOps
3. A GitHub Actions PR workflow will run if additional commits are pushed to the PR branch

The only two steps above that need to be part of the Azure DevOps release are numbers 2 and 6. Number 6 could be part of the Release stage on the build pipeline in YAML (preferred) or as a step prior to the Manual Intervention step (the vote) on the Release pipeline. Number 2 could be fully automated after the Manual Intervention step.

I believe all of the other workflows can be added as GitHub Actions.

Breaking this task down into 6 different workflows, can you think of anything that was overlooked or that cannot be fully automated?

from lucenenet.