Golden tests on your machine catch logic mistakes in the cases their fixtures cover. Running the same checks on every pull request makes sure nothing merges without them, whoever wrote the change. This tutorial sets that up.
What you need
- An Emolysis project in a GitHub repository, with
emolysis.yml,pipelines/andtests/. - Admin rights on the repository, to install an app or change branch rules.
- An Emolysis account on a paid plan.
Step 1: Choose the app or the workflow
There are two ways to run the checks:
- The GitHub App (planned). Install it once on your organization or account and choose the repositories it can see. It asks for read access to contents and metadata, and write access to checks and pull requests.
- The reusable workflow. Reference it from a workflow file in your repository, and the same checks run in your own GitHub Actions, on your runners.
Pick the workflow if your organization prefers not to install apps.
Step 2: Install or reference
The app is planned, so there is no install link yet. For the workflow, add a workflow file that calls the Emolysis workflow on pull requests: a reusable GitHub Actions workflow, in preview, that runs emo check in your own CI; it needs the emo command line, which is not released yet. The GitHub checks docs describe the reusable workflow.
Step 3: Open a pull request
Make a change to a pipeline, for example add a tracked column to an SCD Type 2 dimension. Push a branch and open the pull request.
Step 4: Read the checks
Four checks appear on the pull request:
- Lint: your SQL and Python checked against your platform's rules, with the rule and line for each finding.
- Golden tests: each pipeline's tests run on DuckDB with the fixtures in
tests/. A failure shows the test case and the differing rows. - Cost: an estimate of what the change costs to run on your target platform, with what drives it.
- Preview: a link to a preview dashboard built from the change, for reviewers.
Step 5: Fix a failure
If golden tests fail, run them locally to reproduce. In the app, the agent reads the failure and goes back to the template fill. Push the fix; the checks run again.
Step 6: Make the checks required
In your repository's branch rules, mark the Emolysis checks as required for the main branch. From then on, nothing merges until lint and golden tests are green, and the cost estimate is part of every review.
Step 7: Deploy from main
Deploy from the merged commit with emo run pipeline.deploy, in your CI or by hand. Because the pipeline on main has passed its checks, the deploy gate is the same for everyone on the team. The GitHub checks docs describe the setup in full.
Keep fixtures synthetic
The checks run on the fixtures committed in your repository, and everyone who can read the repository or its CI logs can read them. Use invented values. The post tests before production explains why the fixtures matter.