-
Notifications
You must be signed in to change notification settings - Fork 67
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
base: main
Are you sure you want to change the base?
Actions: Deploy preview docs #66
Conversation
@tristanls I'm flummoxed. None of the docs.yml actions are running and I need help to figure out why. |
@codeallthethingz actions will not pass secrets on |
Ah, right! Thanks. |
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? |
@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:
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this 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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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' |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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: |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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: |
There was a problem hiding this comment.
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: |
There was a problem hiding this comment.
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."
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:
Finished:
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.