Deploy dbt docs to GitHub Pages #57
Conversation
…test_dbt workflow
…tions-workflows-for-building-the-dbt-dag-and-running-tests
…et HEAD_REF env var It turns out that we can't override the GITHUB_HEAD_REF variable in a GitHub Actions workflow, which means we can't set it in order to treat the data-catalog branch environment as a CI target. To get around this, this commit changes up the generate_schema_name macro to read from a new HEAD_REF env var instead of GITHUB_HEAD_REF, and then factors out a configure_dbt_environment composite action that our dbt workflows can use to set this environment variable appropriately.
…flows-for-building-the-dbt-dag-and-running-tests' into 34-data-catalog-define-github-actions-workflow-for-rebuilding-and-deploying-docs-site
… runs on main branch
jeancochrane
changed the base branch from
data-catalog
to
jeancochrane/fix-cleanup-dbt-resources-workflow
jeancochrane
changed the base branch from
jeancochrane/fix-cleanup-dbt-resources-workflow
to
data-catalog
…s-workflow-for-rebuilding-and-deploying-docs-site
| # There is currently no way to early-exit a run with a success status | ||
| # in GitHub actions, so we have to mark each of these steps with the | ||
| # same `if` condition to restrict deploys to successful builds :( | ||
| # https://github.com/actions/runner/issues/662 |
There was a problem hiding this comment.
I think just gating the job with the if statement will prevent the steps from running at all, negating the need for the early exit.
There was a problem hiding this comment.
I think that's correct as well, but I'm testing in 4a46220!
There was a problem hiding this comment.
It turns out we can't test this behavior because both workflow_run and workflow_dispatch will only run if the workflow file exists on the default branch 🙃
Note: This event will only trigger a workflow run if the workflow file is on the default branch.
Are we comfortable merging this without testing and testing on prod instead? Note another downside of this limitation is we won't start building docs until we merge data-catalog into master (#55), but maybe we can bump the timeline on that issue?
There was a problem hiding this comment.
I think that's fine, nothing will break if it fails in prod except for the docs. Let's see how the checks meeting goes re: bumping #55.
jeancochrane
force-pushed
the
34-data-catalog-define-github-actions-workflow-for-rebuilding-and-deploying-docs-site
branch
from
4a46220
to
6399239
Compare
jeancochrane
force-pushed
the
34-data-catalog-define-github-actions-workflow-for-rebuilding-and-deploying-docs-site
branch
from
6399239
to
ec2f703
Compare
jeancochrane
deleted the
34-data-catalog-define-github-actions-workflow-for-rebuilding-and-deploying-docs-site
branch
This PR adds a GitHub Actions workflow for deploying our dbt docs to GitHub Pages. It implements the flow outlined in the GitHub documentation on creating a custom GitHub Actions workflow to publish your site; this feels like a more appropriate choice than publishing from a branch because we don't want to keep our generated docs files under version control if we can avoid it.
For a sample of the deployed site, see: https://ccao-data.github.io/data-architecture
For an example of a successful run that built the site, see: https://github.com/ccao-data/data-architecture/actions/runs/5800847533/job/15723822771
Closes #34.