Repository hygiene · rule repo-no-ci
Data repository with no CI pipeline
A Metacenta review checks this under the rule The repo runs CI. Everything below applies whether or not you ever commission one.
What this rule checks
This rule flags a repository with no CI configuration for a common provider. Workflows under .github/workflows/, .gitlab-ci.yml, a Jenkinsfile and .circleci/config.yml count. So do azure-pipelines.yml, bitbucket-pipelines.yml, .drone.yml and anything under .buildkite/. Each is matched at the repository root only.
Why it matters
Nothing runs the tests or the build before a change lands. Correctness then depends on whoever opened the pull request remembering to check, and a broken change can reach the main branch with no failing run.
How to fix it
Run the build and tests in CI on every pull request. Add a pipeline that installs, builds and runs the tests on every pull request. Start with the build alone if the tests are not ready, and add them as they arrive.
When it is fine to leave
CI configured outside the repository is invisible to this rule. dbt Cloud CI jobs, for example, live in dbt Cloud rather than in a file. So does an in-house runner we do not recognise. Tell us which applies, and the finding comes out of your report.
What we need to check it
Read-only access to the repository's file list. We see that a CI file exists, not what it runs, because we do not read workflow contents. The finding is medium confidence. If the listing was truncated, we decline rather than report.
Published rules it corresponds to
OpenSSF Scorecard, rule CI-Tests. Ours checks the same concern, tested differently. Scorecard checks that CI actually runs tests on pull requests; this engine sees only that a CI configuration is present, since it does not read workflow contents.
This means our check corresponds to their rule. It does not mean the publisher reviewed or endorses it.