Skip to content

ci: use php bin/kcode instead of vendor/bin/kcode#6

Closed
walmir-silva wants to merge 2 commits intomainfrom
develop
Closed

ci: use php bin/kcode instead of vendor/bin/kcode#6
walmir-silva wants to merge 2 commits intomainfrom
develop

Conversation

@walmir-silva
Copy link
Copy Markdown
Contributor

Composer bin-linking only creates vendor/bin/ symlinks for packages installed as dependencies of a project. Within the devkit repository itself, kariricode/devkit is not its own dependency, so vendor/bin/kcode is never created.

Fix: use 'php bin/kcode' directly in all workflow steps.
Applies to: ci.yml (quality job) and code-quality.yml (phpstan, cs-fixer jobs).

Composer bin-linking only creates vendor/bin/ symlinks for packages
installed as *dependencies* of a project. Within the devkit repository
itself, kariricode/devkit is not its own dependency, so vendor/bin/kcode
is never created.

Fix: use 'php bin/kcode' directly in all workflow steps.
Applies to: ci.yml (quality job) and code-quality.yml (phpstan, cs-fixer jobs).
Root cause: without composer.lock, hashFiles('**/composer.lock') returns
an empty string, so all jobs shared the same cache key 'Linux-composer-'.
The security job installed with --no-dev and cached first; subsequent jobs
restored that cache and ended up with a vendor/ missing dev packages.

Fix:
- Remove all Composer cache blocks (no lock file = no stable cache key;
  cold install on ubuntu-latest takes ~15s, not worth the risk)
- Remove --no-dev from security job (composer audit works on installed
  packages — no need for a separate --no-dev install)
- Add --no-scripts to all composer install steps
- php bin/kcode in all kcode steps (vendor/bin/kcode is not created when
  running inside the devkit repo itself)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant