Appearance
Project status
Alongside pull request reviews, a repository can carry a project status: a quick read of how the project is set up, taken from its structure, its documentation and its configuration files.
It is separate from reviews. It never starts on its own, it never reads your application source, and nothing about it reaches your pull requests — no comment, no check run.
Three ways in:
- the Repositories page — selecting a repository opens its project status;
- a repository's settings page → the Project status card → View status;
- in Builder mode, the project list on the dashboard home.
Running a scan
Scans are manual. The page carries one button: Scan project the first time, Scan again afterwards. While one is running it reads Scanning… and is disabled, the status pill pulses, and the page updates itself until the scan settles.
Pushing to the branch does not start a scan — it marks the existing result as out of date instead.
Anyone who can see the repository can run one. Choosing the branch it runs on is an admin's job; see Status branch.
What the statuses mean
The status pill at the top of the page, beside each repository on the Repositories list, and beside each repository in the Builder dashboard list:
| Status | Meaning |
|---|---|
| Looks good | No notable risk signal was found within the light-scan scope |
| Needs attention | The scan found a signal worth reviewing |
| Not enough information | Part of the scan could not be completed |
| Needs update | The branch has changed since the last scan — run it again |
| Not scanned | No scan has been run on this branch yet |
| Scanning… | A scan is running |
| Scan failed | The last scan did not complete |
A single attention signal makes the whole status Needs attention, even when part of the scan was incomplete.
Beside the pill the page shows the status branch, when the last successful scan finished, and the commit it read.
What the scan reads
The repository's file and folder structure on the status branch, plus the contents of a fixed set of files, matched by name:
| Kind | Examples |
|---|---|
| Documentation | README and its common text variants |
| Dependency manifests | package.json, pyproject.toml, go.mod, Cargo.toml, Gemfile, composer.json, pubspec.yaml, requirements*.txt |
| Lockfiles | package-lock.json, pnpm-lock.yaml, yarn.lock, go.sum, Cargo.lock, Gemfile.lock, composer.lock, pubspec.lock |
| Test configuration | vitest.config.*, jest.config.*, playwright.config.*, pytest.ini, tox.ini |
| Tooling configuration | tsconfig*.json, ESLint config, vite.config.*, analysis_options.yaml |
| CI workflows | .github/workflows/*.yml, .gitlab-ci.yml, .circleci/config.yml |
| Deployment | Dockerfile, docker-compose.*, vercel.json, netlify.toml, fly.toml, render.yaml, Procfile, wrangler.*, serverless.*, app.yaml, cloudbuild.yaml, Kubernetes and Helm manifests |
Everything else is left alone. Your application source is never read. Neither is anything under node_modules, dist, build, vendor or .git.
Files that look like secrets — .env files, .pem, .key, .p12, id_rsa — are never fetched. A committed .env file is noticed in the file listing and reported as a signal, but its contents are not read.
The scan reads a limited number of files, and only files under a size limit — lockfiles, which are routinely the largest, are allowed more room than the rest. When there is more to read than those limits allow, lockfiles and dependency manifests are kept and README, tooling and deployment files are the first to go. Anything it leaves out is listed under Files skipped with the reason beside it, and the status drops to Not enough information unless something more serious was found.
See Data and privacy for what is stored afterwards.
The signals
Under the status card, What EasyMerge found (in Developer mode, Scan signals) lists what the scan concluded. Each one is either an attention signal — an amber dot, and enough on its own to make the whole status Needs attention — or informational, with a blue dot.
| Signal | Level | Raised when |
|---|---|---|
| A library used by this project has a published safety issue. | attention when the advisory is high or critical, otherwise informational | A dependency in a manifest or lockfile matches a published security advisory |
| A secrets file appears to be committed to the repository. | attention | A .env-style file is present in the repository |
| EasyMerge recognized the project configuration. | informational | A supported dependency manifest was found |
| Automated tests are configured for this project. | informational | A test configuration file, or a test directory, was found |
| No automated test configuration was found. | informational | Neither was found |
| Automated checks are configured for this project. | informational | A CI workflow file was found |
| No automated CI workflow was found. | informational | None was found |
| Some project information could not be checked. | informational | Part of the scan was incomplete — this is what produces Not enough information |
Compiler and linter configuration — tsconfig.json, ESLint, Vite — never counts as automated tests. A repository carrying those but no test setup reads No automated test configuration was found.
In Developer mode each signal carries its technical wording instead, with the file it came from and, for a dependency advisory, the advisory identifier.
Files inspected and skipped
In Developer mode the page ends with two lists: every file the scan read, and every file from the list above it left out, each with its reason — file count limit, file size limit, total size limit or fetch failed. Builder mode omits both.
When a scan fails
The page keeps the previous result and heads it The latest scan failed., with The result below is from the last successful scan.
| Message | What to do |
|---|---|
| The selected branch no longer exists on GitHub. | Pick another branch under Status branch |
| No supported project files were found on this branch. | Nothing on the list above is present — there is nothing for a light scan to read |
| GitHub temporarily refused the repository contents request. | Try again shortly |
| The scan timed out. | Try again |
| The scan failed unexpectedly. | Try again; if it repeats, report it |
What it is not
The page says so itself: Light scan reads repository structure and allowlisted documentation/config files. It does not read application source or prove that the application is defect-free.
It is not a security audit, not a review, and not a substitute for either. Pull request reviews are unaffected by it — see Reading a review.