I think this deserves an entry in the changelog. What do you think?

@sbuerk provided some more feedback and recommends to not use config/ for this as this by convention is the production configuration folder for TYPO3 sites. I'll put this up for decision in the next call.

Ok, I'm not sure if this was decided, can't find it in meeting minutes

@oliverklee @sbuerk should we use Build/ ?

@oliverklee @sbuerk should we use Build/ ?

If you ask me, yes. That's also the folder the TYPO3 core uses for these things of tool configurations (with sub-folders per tool) and core merger/contributors adopted for extensions and projects.

I talked with @oliverklee and @DanielSiepmann on that already. In the end, it's about naming with some requirements:

• folder to keep root-folder clean
• not using a folder name which contains extension related stuff (ex. Configuration/ ) in the TYPO3 world

There are other preferences, which you should discuss/define within the team first I guess. For example stying on the root-folder / default naming.

Personally, Build/ suits most perfectly for these kind of stuff. I would stay way from things like etc/ or namings used in other contexts not suiting the need.

Pull Request Test Coverage Report for Build 9165103416

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 100.0%

Totals
Change from base Build 9164456450:	0.0%
Covered Lines:	46
Relevant Lines:	46

💛 - Coveralls

I propose we split this PR up into "one tool per PR". This makes the reviews easier, reduces the risk of us missing things, and helps get the changes merged faster.