Migrate glpi-project/tools to core

[froozeify]

Checklist before requesting a review

Please delete options that are not relevant.

• I have read the CONTRIBUTING document.
• I have performed a self-review of my code.
• I have added tests that prove my fix is effective or that my feature works.
• This change requires a documentation update.

Description

Migrate https://github.com/glpi-project/tools into the core with also a converted python/bash scripts so all are runned as Symfony Command.

Doing that migration will avoid the dependencies exception libraries could have when they were requiring a different glpi-project/tools

For the future we could put glpi-project/tools as archived but we can't remove it from packagist as plugin supporting prior to GLPI 11.0.5 version would have to still install that library.

It's can be release in 11.0.5 as it was currently only a dev dependencies, so in worth case if the user try to run a command it will just not work.
It will force local dev env to be up to date (or at least be in 11.0.5-dev)

Template https://github.com/pluginsGLPI/empty should also be updated to remove that composer dependency once this PR is merged.

TODOs

• LicenceHeadersCheck
• CompileTwigTemplate
• ExtractLocals (migrate this to /tools not /tools/plugins ???)
• PluginRelease
• PHPStan Rules (already present in core MissingGlobalVarTypeRule)

What was done

• Migrate LicenceHeadersCheckCommand.php and CompileTwigTemplatesCommand.php (no major edit - namespace and print changes)
• Convert plugin-release python file to PHP
• Convert extract-local bash file to PHP

Interconnected PR (merge order) :

• Fix common dependencies check exception when composer.json has no dependencies plugin-ci-workflows#50
• Migrate glpi-project/tools to core #22465
• Remove glpi tools dep pluginsGLPI/empty#57

Plugins CI

• Switch to GLPI core tools plugin-release-workflows#10
• Switch to GLPI core tools plugin-translation-workflows#9

Whatsapp plugin got a dedicated PR to test the modification (see in the feed under for the link)

[AdrienClairembault]

I think you'll need to rebase and update the header (2026)

[trasher]

This PR is very huge. Should not be splat into smaller parts easier to follow and review?

[cedric-anne]

Except added tests are failing, it seems technically OK. I will do some manuel tests to compare results with the scripts from glpi-project/tools.

[froozeify]

Except added tests are failing, it seems technically OK. I will do some manuel tests to compare results with the scripts from glpi-project/tools.

Fixed it was due to the fact that the pot file didn't exist in test and previous code would not run the file creation (php would only run the file_exist in the if condition)

[trasher]

@Rom1-B @stonebuzz could you please test on your side the plugin release process from this PR?

[stonebuzz]

This should also be updated accordingly.

https://github.com/glpi-project/plugin-release-workflows/blob/v1/.github/workflows/publish-release.yml

https://github.com/glpi-project/plugin-translation-workflows

[froozeify]

This should also be updated accordingly.

https://github.com/glpi-project/plugin-release-workflows/blob/v1/.github/workflows/publish-release.yml

https://github.com/glpi-project/plugin-translation-workflows

Done in PRs :

• Switch to GLPI core tools plugin-release-workflows#10
• Switch to GLPI core tools plugin-translation-workflows#9

They should be merged once this one is deployed as it will be based on the source code here (for now I tested them using a fork)

[cedric-anne]

We can merge this PR without breaking existing plugins ci/release/translation workflows.

These workflows will be updated to keep using glpi-project/tools from the plugins vendor if they are found, and with a fallback to the new commands introduced here. This will permit to migrate plugins one at a time, and will give the ability to put back the glpi-project/tools dependency to a migrated plugin to temporarly bypass any issue present in the new commands.

[cedric-anne]

After thinking about the way the plugin export command would be used, I think it could be drastically simplified:

• with a unique dest parameter that corresponds to the path of the destination file e.g. --dest=~/build/glpi-myplugin-preversion-20260129.tar.bz2;
• in combination with the --auto-compress tar option, instead of -j to allow usage of other compression formats (e.g. .tar.gz);
• using the git checkout-index command, like we do in the make_release.sh script, instead of git ls-tree + git archive + untar;
• moving the "banned files" cleaning at the end of the process, right before the archive creation.

[github-actions]

This PR has been is closed and has been automatically locked. Please open a new issue with all requested information for related bugs.