Add rector.yaml to .dockerignore

[aboks]

Context:
I'm trying to use the Rector docker image to upgrade a testsuite from PHPUnit 6 to PHPUnit 8.

Symptom:
Rector refuses to process files in a directory named tests. It only finds these files if I create an 'empty' rector.yaml configuration file in my project and specify it on the command line using the -c flag.

Analysis:
It turns out that when no config file is specified as a command line option, Rector looks for one in its current working directory. In the docker image, this is /rector, the directory containing the source files of Rector itself. Among these is rector.yaml, which is the Rector configuration file for developing on rector itself (at least I think so). This file contains an exclude pattern for /tests/, which is useful when working on Rector itself, but is now also used as an exclude when applying Rector on another project.

Proposed solution:
The rector.yaml configuration file for developing on rector itself should never be used by default in runtime. We can do so by adding it to .dockerignore, so that it is excluded from the docker image.

[JanMikes]

Please, what exact command are you trying to run?

You always need either some set or config to run rector with, right @TomasVotruba ?

I see what your issue is, but i need more data, to make sure you are using the Docker image in correct way.

@TomasVotruba if someone runs rector with --level option, is rector.yaml ignored? Is it required to exist in the project or can be skipped if running with --level?

[aboks]

I'm running

docker run -v $(pwd):/project rector/rector:latest process /project/test --level phpunit80 --autoload-file /project/vendor/autoload.php --dry-run

This skips all files within the test/tests-directory. If I put an 'empty' rector.yaml in my project directory and run rector with

docker run -v $(pwd):/project rector/rector:latest process /project/test --level phpunit80 --autoload-file /project/vendor/autoload.php --dry-run -c /project/rector.yaml

it correctly finds the test files.

[JanMikes]

Thank you!

@TomasVotruba what do you think about ignoring and not requiring rector.yaml when running with --level? Does it make sense to you? That workaround with creating empty config is working but not the best UX.

[TomasVotruba]

What's common approach for CLI tools with non-config sets out there? E.g.
phpstan or phcsfixer

[JanMikes]

I think they all need some config and do not support running without that, but nothing really similar that rector has - you have for example prepared yaml configs that can be used instead of writing your config, that is imho same thing as --level is doing (i can understand it as shortcut for passing path to the config yaml file).

[TomasVotruba]

The sets only contain rules. The rector.yaml is needed to load parameters, e.g. PHP version etc. So this is expected behavior.

Not sure how this is related to Docker though

[TomasVotruba]

Among these is rector.yaml, which is the Rector configuration file for developing on rector itself (at least I think so)

I see now, that's the issue

[TomasVotruba]

Thanks for the PR!

[JanMikes]

The rector.yaml is needed to load parameters, e.g. PHP version etc. So this is expected behavior.

Well, this is not true. I tried the command above and it works without any rector.yaml - by adding it to .dockerignore it is missing and either project has no rector.yaml file and it still works.

▶ docker run -v $(pwd):/project rector/rector:latest process /project/test --level phpunit80 --autoload-file /project/vendor/autoload.php --dry-run

Rector No version set (parsed as 1.0.0)@


 [OK] Rector is done! 0 changed files    

So the behavior is maybe not documented, but it works by some magic 😄

[TomasVotruba]

Well, this is not true.

You're read it too conditionally :D It is needed, IF you want to configure parameters

[JanMikes]

Ok, i think i undestand now 😄 im looking forward to the prefixed version, with that we will be able to set working directory inside of docker to project instead of rector's working diretory, i feel this is more likely workaround than solution of a problem.

But it works, so thank you for PR 😉

[TomasVotruba]

As Steve would say: "Better done than perfect" :)

[aboks]

Thanks for the quick merge!