TIA: the fingerprint ignores the config actually in use (-c / --configuration)

Open
#1,858 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
68/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
php
Domain
testing

Research direction

Start in src/Plugins/Tia/Fingerprint.php at Fingerprint::compute() and trackedHash(), then trace how the active PHPUnit configuration path is resolved from the command-line options. Verify that the fingerprint changes for different active configurations and for a local configuration that is not tracked by git.

Written by the indexing model from the issue text.

Description

Fingerprint::compute() hashes hardcoded paths:

// src/Plugins/Tia/Fingerprint.php:36-37
'phpunit_xml'      => self::trackedHash($projectRoot, 'phpunit.xml'),
'phpunit_xml_dist' => self::trackedHash($projectRoot, 'phpunit.xml.dist'),

Nothing consults the -c / --configuration path in use. configuration, argv, PHPUNIT_ and getopt each appear 0 times in that file.

Effect: pest --tia and pest --tia -c alternate.xml share one graph, although the two configs can declare different testsuites, different excluded groups, different bootstrap and different source roots. Switching config does not invalidate the graph.

Second gap, same helper: trackedHash() returns null for anything not tracked by git (:255-262, isTrackedByGit() at :264), so an untracked local phpunit.xml gets no fingerprint coverage at all.

Fix: hash the resolved active config path, and hash it whether or not it is tracked.

v5.1.0.

Related, same root cause — the fingerprint's input set being incomplete: #1856 (git HEAD not covered) and #1857 (php_minor holds the major version). Three independent gaps found in one sitting, which may argue for widening the input set rather than patching the fields.

Dominant language
PHP
Stars
11.7k
Forks
538
Avg merge
4d 11h
Merged PRs (30d)
8

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from pestphp/pest

All issues in pestphp/pest

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.