You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucenenet.apache.org by GitBox <gi...@apache.org> on 2020/05/27 05:14:02 UTC
[GitHub] [lucenenet] Shazwazza opened a new issue #290: Docs - automate the website updates when publishing new docs
Shazwazza opened a new issue #290:
URL: https://github.com/apache/lucenenet/issues/290
Depends on #282
Part of the docs building process is to update the website with new links/pages to the docs. This part should be automated.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [lucenenet] NightOwl888 edited a comment on issue #290: Docs - automate the website updates when publishing new docs
Posted by GitBox <gi...@apache.org>.
NightOwl888 edited a comment on issue #290:
URL: https://github.com/apache/lucenenet/issues/290#issuecomment-733806638
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](https://issues.apache.org/jira/browse/INFRA-17030), 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](https://docs.github.com/en/free-pro-team@latest/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpaths) on a [GitHub Actions workflow](https://github.com/apache/lucenenet/blob/e814b284e094a5bc7ddf3afe7b72868bcc3b0554/.github/workflows/Lucene-Net-Tests-Analysis-Common.yml#L25-L42) 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](https://devblogs.microsoft.com/devops/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?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [lucenenet] NightOwl888 commented on issue #290: Docs - automate the website updates when publishing new docs
Posted by GitBox <gi...@apache.org>.
NightOwl888 commented on issue #290:
URL: https://github.com/apache/lucenenet/issues/290#issuecomment-733806638
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/ 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](https://issues.apache.org/jira/browse/INFRA-17030), 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](https://docs.github.com/en/free-pro-team@latest/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpaths) on a [GitHub Actions workflow](https://github.com/apache/lucenenet/blob/e814b284e094a5bc7ddf3afe7b72868bcc3b0554/.github/workflows/Lucene-Net-Tests-Analysis-Common.yml#L25-L42) 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](https://devblogs.microsoft.com/devops/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?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org