Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Actions: Deploy preview docs #66

Open
wants to merge 27 commits into
base: main
Choose a base branch
from

Conversation

codeallthethingz
Copy link
Contributor

@codeallthethingz codeallthethingz commented Nov 24, 2024

This PR creates a set of hidden docs on readme.com with a version matching the current version of the docs up to the minor version + the branch name made safe for metadata on a semver version.

For example, this branch: 0.0-deploy-preview-docs

While building it puts a sticky note on the PR's comments

Building:
image

Finished:
image

Failure:
Similar to building but with a ❌

This PR needs some action secrets / vars to be created.

Note

Currently preview docs are not deleted when they are merged to main, this will be done in a separate PR.

@codeallthethingz codeallthethingz marked this pull request as draft November 24, 2024 14:11
@codeallthethingz codeallthethingz marked this pull request as ready for review November 24, 2024 14:27
@codeallthethingz codeallthethingz added infrastructure Changes to infrastructure triaged This issue or pull request was triaged labels Nov 24, 2024
@codeallthethingz
Copy link
Contributor Author

@tristanls I'm flummoxed. None of the docs.yml actions are running and I need help to figure out why.

@tristanls
Copy link
Contributor

@codeallthethingz actions will not pass secrets on pull_request trigger event. It'll need to be pull_request_target and in main before it passes secrets. This is what happened with CLA check.

@codeallthethingz
Copy link
Contributor Author

Ah, right! Thanks.

@codeallthethingz
Copy link
Contributor Author

I tried to add a trigger of both pull_request and pull_reqeust_target the docs.yml, but I feel like the entire file is skipped if there is a reference to a secret in it, which I think means I need to split the docs.yml into two - one for the secretless check-docs and one for the secretfull preview-docs. Do I have that right?

@codeallthethingz
Copy link
Contributor Author

@tristanls I split the file into two, and the action that need a secret, triggers on pull_request_target. Let me know if this is the right approach overall.

If the above is correct:

  • There is now a repeating chunk of yaml should_run_docs that could be extracted into a common file.
  • Also, I wasn't sure of the naming convention now we have two "docs" type actions. Let me know what might be a good naming strategy.

Also, this can all wait till Monday.

@@ -90,7 +91,7 @@ jobs:
echo $changed_file
if [[ $changed_file == docs/* ]] ||
[[ $changed_file == tools/github_readme_sync/* ]] ||
[[ $changed_file == .github/workflows/docs.yml ]]; then
[[ $changed_file == .github/workflows/docs* ]]; then
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might be too greedy a match?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue: The rationale for including the workflow file path here is to ensure the workflow is triggered when the workflow file changes, even if nothing else changes. I don't think we should trigger this workflow if some unrelated workflow file changes.

Copy link
Contributor

@tristanls tristanls left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding naming suggestions, I think Docs and Docs Preview make sense.

Docs leads to check-docs, should-run-docs.
Docs Preview leads to deploy-docs-preview.

These appear coherent to me.

steps:
- name: Create initial PR comment
if: ${{ needs.should_run_docs.outputs.should_run_docs == 'true' }}
uses: marocchino/sticky-pull-request-comment@v2
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue (blocking) Our security policy does not permit the execution of actions by unverified creators.

@@ -1,4 +1,4 @@
name: Docs
name: Docs Check
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue: Changing this calls for changing the job names per our naming convention.

I've referenced our naming convention in other PRs, but having it in the style guide is probably good. While it is not there yet, this PR adds it and can be a reference: #69.

@@ -18,6 +18,7 @@ jobs:
runs-on: ubuntu-latest
needs:
- should_run_docs
if: github.event_name == 'pull_request'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question: Why would we not check the docs when merging to main?

@@ -90,7 +91,7 @@ jobs:
echo $changed_file
if [[ $changed_file == docs/* ]] ||
[[ $changed_file == tools/github_readme_sync/* ]] ||
[[ $changed_file == .github/workflows/docs.yml ]]; then
[[ $changed_file == .github/workflows/docs* ]]; then
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue: The rationale for including the workflow file path here is to ensure the workflow is triggered when the workflow file changes, even if nothing else changes. I don't think we should trigger this workflow if some unrelated workflow file changes.

- main

jobs:
deploy_preview_docs:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue: Should follow the naming convention described in #69.

run: |
export PATH="$HOME/miniconda/bin:$PATH"
source activate tbp.monty
echo "VERSION=$(python -m tools.print_version.cli minor)" >> $GITHUB_ENV
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion (non-blocking): It may be safer to namespace when using a shared environment, e.g., MONTY_VERSION.

# Remove trailing dash if present
echo "BRANCH_NAME=$(echo ${GITHUB_HEAD_REF} | tr -c '[:alnum:]' '-' | sed 's/-*$//')" >> $GITHUB_ENV
# Get current date in ISO format
echo "DATE=$(date -u +'%Y-%m-%d %H:%M UTC')" >> $GITHUB_ENV
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion (non-blocking): It may be safer to namespace when using a shared environment, e.g., MONTY_DATE.


Check the [workflow logs](${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}) for details.

should_run_docs:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue: Should follow the naming convention described in #69.


Check the [workflow logs](${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}) for details.

should_run_docs:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion: For non-required checks, we do not need to go through an artisanal setup of "should run," as seen in other workflows.

We can use the default paths filtering mechanism when a check is not required. See https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore.

The artisanal "should run" code is necessary elsewhere because when a workflow is skipped using the paths mechanism above, it registers as "skipped" instead of "success." However, a required check must "succeed" and cannot be "skipped."

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
infrastructure Changes to infrastructure triaged This issue or pull request was triaged
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants