Status of Drupal tools: November 2021

Authored on
Changed

A review of the last 7 months since the last article on this subject.

I'm going to highlight some changes, it would be pointless to list them all here, most are minor or are fixes in relation to concrete use of skeleton on projects.

To see all the differences:

Reverse Proxy Traefik

MacOS support has been added with the added bonus of Make commands to launch Traefik depending on the OS and also the ability to launch it on autostart without any files to modify.

For MacOS support on the skeleton, there is currently an MR, functional for one project but a priori not working if you want several projects started in parallel.

PHP Psalm

In the previous article, I indicated that I had left this tool aside because I hadn't found a suitable configuration.

I persisted and eventually found the commands to run beforehand and above all how to configure the tool to enable " tainted " mode for security analysis.

This allowed me to discover a security issue on File Extractor and Search API Attachments. Following this, I therefore made the display of CI Pipelines results private in order to avoid displaying publicly if a security issue was found.

If any other security issues are found, they will be reported to the Drupal security team.

It's a shame that it's not possible to hide CI results on certain tasks or branches.

Cypress

As with PHP Psalm, my initial trials of Cypress were not very positive. I tried again to add it to my stack and succeeded for local use.

In fact, I want to be able to use the Docker Cypress images and not have to maintain my own, it works locally. So I made different Make commands to launch a Cypress container already containing several browsers.

For use in Gitlab CI, following consultation of numerous tutorials and articles on the subject, I didn't manage this point because in all these examples, there is constant talk of testing a JS application and so the NodeJS container that runs the application "simply" has to have Cypress and the tests are run on that same container. Cypress can't be added as a service and driven from the PHP container, like Chromedriver with PHPUnit tests (at least not to my current knowledge).

This would require adding Cypress directly into my CI PHP image, which I want to avoid because, Cypress has many prerequisites and you need to install the browsers you want for testing in a specific version, which would increase the size of my images for a tool I don't use enough yet to justify this setup.

I'll come back to the use of Cypress in a future article.

Scripts (lots of scripts...)

The scripts have been almost entirely reworked to allow :

  • multi-site management (useful just for the example branch of environment with Entity Share),
  • packaging for a target environment for a given branch or Git tag,
  • deployment on a target environment with separation of stages to enable one site to be updated after another and thus reduce the time taken to put each site into maintenance mode and defer version upgrades if required. The various separate stages :
    • source deployments
    • release activation symbolic links
    • update
  • deployment on an environment with Docker used to run the project,
  • an addition of scripts and Make command to have a minimum of administration of remote sites :
    • creation of backup (possibility to backup public and private files),
    • delete backup,
    • restoring a backup,
    • I have not made a script for purging releases because for the moment by necessary and there may be different needs, because it must be verified that there is no longer a site that uses the release to be deleted for example.
  • secret management, to avoid versioning passwords for example :
    • Gitlab CI is mostly integrated with the Vault solution and not much else. So I looked into Bitwarden CLI and unfortunately even with API keys you have to make a master password available, which isn't great. So I opted for a dual system: for scripts run locally, it's possible to manage passwords stored in a Bitwarden. And for use in Gitlab CI, you need to fill in environment variables in Gitlab CI and there will be a replacement on the fly.
  • the generalisation of the use of .env files, even for the Gitlab CI environment,
  • the use of environment variables for Drush aliases, in order to continue to have as much configuration as possible managed via .env files.

Also note that now there is a possible use of hook_deploy.

I used to be reluctant to use them, with my contrib module maintainer hat on, because these hooks are not usable in this context and because they are not triggered if an update is made via the Drupal interface. But updates are always performed via Drush. And finally it made me use hook_post_update instead of hook_deploy, which the former are not made for.

Documentation

The changes are documented in the docs folder, maybe the documentation needs to be reorganised, I'll see with use.

For the PHPStorm settings, I made a French version on the site.

Conclusion

After 7 months of heavy modifications/improvements, I'm certainly forgetting to highlight certain changes.

I'm now using all these new features to deploy my site via Gitlab CI !

After this milestone, the next steps are :

After that, I think I'll mark the progress again before embarking on a rewrite of the scripts to avoid duplication of code between :

  • the scripts for administering the local environment from those for remote environments,
  • the Makefile commands and the .gitlab-ci.yml file.

The shell is very powerful, but it has lots of side effects and I'm starting to overdose on it. Environment variables are cool, but it's not really possible to manage lists and nested configuration with them.

Acknowledgements

Thanks to :

If I've forgotten any contributors, please don't hesitate to let me know.

Comments

Add new comment

About text formats