lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [lucenenet] NightOwl888 edited a comment on issue #290: Docs - automate the website updates when publishing new docs
Date Wed, 25 Nov 2020 16:23:57 GMT

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



Mime
View raw message