The following are changed:
- web-dir: ".Build/public" => ".Build/Web"
- bin-dir: not specified, defaulted to .Build/vendor/bin
=> ".Build/bin"
The vendor-dir was alreaday ".Build/vendor" and is left
unchanged.
Since the above paths may be used in scripts, composer.json,
build pipelines, configuration etc. it facilitates
contribution across various extensions (and the core) if
the same defaults are used.
The goal of patches related to #802 is to unify the paths
across TYPO3 extensions, specifically focusing on the
"official" extensions (such as tea, Documentation examples
extension etc.).
- .Build has already been well established (and is used by
"tea" as well.
- web-dir (".Build/Web") is currently not used consistently
(across official extensions). Either ".Build/public", ".Build/Web"
or ".Build/web" or "public" is used. We use ".Build/Web"
now as that is already well established in "styleguide"
and other extensions. (This choice is not better than
the other, but is more commonly used and has led to a
consensus in preliminary decision making process.)
- bin-dir: Here ".Build/bin" is mostly used (if defined at all)
- vendor-dir: Here ".Build/vendor" is mostly used (if defined
at all)
Related: #802
Our current automerging CI task does not work reliably.
So instead of using a GitHub Action that does the automerging itself,
we are now using a GitHub Action that only triggers GitHub's own
automerge feature (which works a lot more reliably).
Now dependency updates by Dependabot will be automerged if/when all
required checks are green.
This will reduce the repetetive work of merging all these update
PRs, and we have been heavily relying on our CI pipeline to check
if a depenceny update is safe to merge anyway.
Attaching any of the labels `wip` or `blocked` to a PR will block the
automerging.
Case-insensitive filesystems cannot distinguish properly for
file and folder names with different casings. This leads to
unforseeable issues on these systems, like default partition
on MacOS devices from apple or eventually Windows systems.
This change configure phpcoverall and the chain explicitly to
use folders for the files which differs from the default of
`build/*` to avoid conflicts on case-insensitve filesystems
and prepare for introduction of the upcoming implementation
of TYPO3 core recommended `Build/` structure.
Co-authored-by: Stefan Bürk <stefan.buerk@impactmedia.de>
This way, the Composer dependencies are consistently in
ascending order in the CI matrix (as are the PHP and TYPO3 versions).
This is the same as #617 (which rearranged the CI matrix entries
for the Composer-script-based CI jobs), but for the CI jobs using
the predefined GitHub Actions (this time for the unit tests).
Part of #578
This way, the Composer dependencies are consistently in
ascending order in the CI matrix (as are the PHP and TYPO3 versions).
This is the same as #617 (which rearranged the CI matrix entries
for the Composer-script-based CI jobs), but for the CI jobs using
the predefined GitHub Actions.
Part of #578
Also sync the test matrices of the `predefined` CI jobs with those
from the Composer-script-driven CI jobs.
This change does not add any 7.4-only PHP language features.
Fixes#577
The `typo3/minimal` package is not maintained very much, and currently
cannot be used as a requirement to install the latest TYPO3 development
version (as it still depends on `dev-master`, not on `dev-main`).
In addition, not depending on it will allow us to find any missing
dependencies in our requirements that so far have been masked by
the `typo3/minimal` dependencies.
PHP version numbers need to be strings: If the version `8.0` were
treated as a number, the YAML parser would happily convert it to `8`,
hence dropping the minor version number.
- Move npm tools and config to default places
- Remove now unnecessary config file parameter from npm scripts
- editorconfig and eslint config contradict, adapt editorconfig
- switch JS indent linting to TYPO3 coding standard of 2 spaces
- adapt composer scripts for new npm location
Having a consistent structure and order between the CI jobs and the
code coverage generation job makes understanding the GitHub Actions
configuration easier.
It also allows having a shared Composer cache between the non-coverage
jobs and the coverage job.
There is no need to have the code coverage data directly generated by
the tests run in a non-hidden directory. So now the code coverage is
recorded within `.Build/coverage`.
Only the merged coverage data still needs to be located in `build/logs`
as Coveralls (which we're planning to use) relies on this.
The installed Composer packages will be different depending on the
major TYPO3 version being tested and on the strategy for the
dependencies (highest, lowest). So it makes sense to have
separate Composer caches for these versions in order to avoid
cache misses.
