Running `duster lint` fails when no files checked

[mattstauffer]

Moving this from #198 to separate the issues.

@Quellens (#198 (comment)) said:

I just run duster lint
maybe it is a different issue, but the same error message.

So locally, i can run it with this output:
(successful duster lint run)
The Codesniffer works here, but i dont know, why the pipeline doesnt work.

So I just have one .blade.php file, and many normal .php files in the project directory.

I don´t know if it helps, but this is the .phpcs.xml.dist
(config here)

[mattstauffer]

@Quellens the fact that it's working for you locally but not in CI makes me suspect your CI is using an older version. Can you share how your CI is configured? Thanks!

[Quellens]

I think, this are all relevant CI-Configurations for this problem. I kept some things private for safety.

stages:
  - build
  - inspect

build-image-tooling:
  services:
    - docker:dind
  image: ${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX}/library/docker:dind
  tags:
    - docker
  variables:
    DOCKER_HOST: tcp://docker:2375
    DOCKER_TLS_CERTDIR: ""
    DOCKER_DRIVER: overlay2
  stage: build
  before_script:
    - mkdir -p $HOME/.docker/
    - docker login -u "$CI_DEPENDENCY_PROXY_USER" -p "$CI_DEPENDENCY_PROXY_PASSWORD" "$CI_DEPENDENCY_PROXY_SERVER"
  script:
    - docker buildx build
      --build-arg IMAGE_PREFIX=${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX}/library/
      --progress=plain
      --tag $CI_REGISTRY_IMAGE/tooling:$CI_COMMIT_BRANCH
      --file docker/tooling/tooling.Dockerfile .
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker push $CI_REGISTRY_IMAGE/tooling:$CI_COMMIT_BRANCH
  after_script:
    - docker logout

build-be-dev:
  tags:
    - docker
  stage: build
  image: $CI_REGISTRY_IMAGE/tooling:$CI_COMMIT_BRANCH
  needs:
    - job: build-image-tooling
  script:
    - composer install --optimize-autoloader --no-suggest --no-interaction
  artifacts:
    paths:
      - vendor/

inspect-be:
  tags:
    - docker
  stage: inspect
  image: $CI_REGISTRY_IMAGE/tooling:$CI_COMMIT_BRANCH
  needs:
    - build-be-dev
  script:
    - vendor/bin/duster lint

Here are some relevant information in the dockerfile

ARG IMAGE_PREFIX=""
FROM composer/composer:latest-bin as composer
FROM ${IMAGE_PREFIX}php:8.3-fpm-alpine

RUN apk update && apk add \
    libzip-dev \
    unzip \
    zip \
    git

# PHP-Extensions
RUN docker-php-ext-install pdo_mysql zip bcmath intl

# composer
COPY --from=composer /composer /usr/bin/composer

Duster version is the latest version, its the same locally.

[AliceKLWilliams]

@mattstauffer We had a similar issue recently (where Codesniffer was running and working locally, but not in our CI Pipeline), and I believe it was because our CI (in GitLab) was storing our code in a /builds/ folder - which Duster is set to ignore by default.

Sounds like it could be a similar issue here?

Thought I would post in case this helps!

[psuet]

I have exactly the same problem. I verified that this was introduced between v3.3 and v3.4.0 by only changing the duster version in our CI.

We have quite a similar setup to @Quellens. Entire Laravel Project with mutiple php and blade.php files.

Dockerfile:

FROM node:current-alpine AS node

WORKDIR /var/www/html
COPY package.json package-lock.json /var/www/html/

RUN npm ci

COPY . /var/www/html
RUN npm run build

FROM ghcr.io/serversideup/php:8.5-fpm-nginx-alpine

USER root

WORKDIR /var/www/html
SHELL ["/bin/sh", "-o", "pipefail", "-c"]

ENV AUTORUN_ENABLED=true
ENV PHP_OPCACHE_ENABLE=1
ENV TZ="Europe/Berlin"
## Install php extensions
RUN install-php-extensions gd ldap

USER www-data

COPY --chown=www-data:www-data composer.json composer.lock /var/www/html/

RUN composer install --optimize-autoloader --no-interaction --no-plugins --no-scripts --prefer-dist --no-dev

COPY --chown=www-data:www-data --from=node /var/www/html/public/build /var/www/html/public/build
COPY --chown=www-data:www-data . /var/www/html

.gitlab-ci.yml (shortend):

stages:
  - lint
  - build

docker-build:
  image: docker:cli
  stage: build
  services:
    - docker:dind
  variables:
    DOCKER_IMAGE_NAME: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
  before_script:
    - echo "$CI_REGISTRY_PASSWORD" | docker login $CI_REGISTRY -u $CI_REGISTRY_USER --password-stdin
  script:
    - docker build --pull -t "$DOCKER_IMAGE_NAME" .
    - docker push "$DOCKER_IMAGE_NAME"
  rules:
    - if: $CI_COMMIT_BRANCH
      exists:
        - Dockerfile
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      exists:
        - Dockerfile

test:duster:
  stage: test
  needs: ['docker-build']
  interruptible: true
  image: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
  before_script:
    - composer install --optimize-autoloader --no-interaction --no-plugins --no-scripts --prefer-dist
  script:
    - vendor/bin/duster lint
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      changes:
        - .gitlab-ci.yml
        - composer.json
        - composer.lock
        - "**/*.php"

If necessary I can provide a minimal test repository and runner for testing.

[AliceKLWilliams]

We believe that before the update it wasn't running Codesniffer on any files in the project on CI (due to the folder being ignored). It was only in this recent update that this situation then causes an error which has surfaced the issue.

[mattstauffer]

Thanks all! Yes, @psuet and any others, I'd love help creating the absolute minimal test respository and runner.

I haven't figured out yet whether this is about the shape of the repo, of the config, or of the runners.

I really appreciate all of y'all's help!

[Quellens]

I can confirm, that this issue is new in 3.4.0.
I downgraded the duster version to 3.3.0 and the problem does not exist.

My Code also runs in a builds folder:

root@b67151960ddb main # pwd
/builds/main

root@b67151960ddb main # vendor/bin/duster --version
Duster 3.4.0
root@b67151960ddb main # vendor/bin/duster lint
 => Linting using TLint 
 >> success: No issues found. 
 => Linting using PHP_CodeSniffer 
ERROR: No files were checked.
All specified files were excluded or did not match filtering rules.

Downgrade:

vendor/bin/duster --version
Duster 3.2.0
root@b67151960ddb main # vendor/bin/duster lint
 => Linting using TLint 
 >> success: No issues found. 
 => Linting using PHP_CodeSniffer 


Time: 51ms; Memory: 25.01MB

 => Linting using PHP CS Fixer 

───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── Laravel  
    PASS   .............................................................................................................................................................................................. 128 files  

 => Linting using Pint 

  .......................................................................................................................

  ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── Laravel  
    PASS   ..........

Maybe it has something to do with this change?
https://github.com/tighten/duster/pull/191/changes#diff-198e0023048771640f8548e36274568daeeb9a57a6afba5756cb8584c54197e8

I hope that helps!

[stf-alexander]

Hey guys,

we are having the exact same problem on our GitLab Pipeline with the latest version of duster (v3.4.2).

=> Linting using PHP_CodeSniffer ERROR: No files were checked.

Any ideas how to fix this ? 🙂

[Quellens]

Either wait for the fix (#204) or downgrade to version 3.3 🙂

[mattstauffer]

OK, thank you all so much for your patience! I was researching a concern I had about this, but I think we'll be able to merge in #204 and just be fine. So I merged it and tagged https://github.com/tighten/duster/releases/tag/v3.4.3.

I'd love your help testing this out in your situations. Based on my understanding this will fix for everyone except @psuet, but it'd be great if it fixes for everyone!

Again, thank you so much for your patience.

[Eino-creator]

We are still getting the issue with version 3.4.5. Seems that the dirty flag is still the issue. Using lint without the dirty flag does not flag the issue.

[mattstauffer]

@Eino-creator gahhhh ok, let me see if i can repro. I may need your help!

[gcavanunez]

@Eino-creator We just released v3.4.6, which includes a fix for an exclusion pattern that could incorrectly treat certain PHP files as excluded when using --dirty.

We reproduced the failure on v3.4.5 (steps) and verified that v3.4.6 checks the dirty file correctly. Could you update and try again?

[indykoning]

I'm still running into the issue on 3.4.6 and running in bitbucket pipelines
The tool call is /opt/atlassian/pipelines/agent/build/vendor/bin/duster so adding the / after the ignore folders will not help in this case.

I reckon we'd need to change the check or glob here

duster/app/Support/DusterConfig.php

Line 58 in 28c5a95

->reject(fn ($path) => in_array($path, static::$defaultExclude))

so we can turn it into a relative path instead of the absolute path containing /build/

[selfsimilar]

We hit this on Bitbucket Pipelines and traced the mechanism: DusterConfig::scopeConfigPaths() always merges a default exclude list containing the bare string build, which PhpCodeSniffer::process() passes as --ignore=…,build,…. PHPCS applies ignore patterns as substring regexes against absolute file paths — and Bitbucket clones every pipeline into /opt/atlassian/pipelines/agent/build/, so the build pattern matches every file in the repo. PHPCS then exits with "ERROR: No files were checked" and duster fails the run.

Reproduce anywhere: clone any Laravel project into a directory whose path contains /build/ and run duster lint --using=phpcodesniffer — 100% reproducible on v3.4.6; the same tree lints clean from a path without build. GitHub Actions is unaffected (/home/runner/work/...), which may be why this mostly surfaces from Bitbucket users. A fix could anchor the default excludes to the project root before handing them to PHPCS. Our interim workaround is copying the checkout to /tmp/src and linting there.

[Comment drafted by Claude Code Fable]