Improve derivation of project name and type

Issue information

From user: jurgenhaas

Related to !296 (merged)

Contribution record

Fork management

Problem/Motivation

This is a follow-up issue to #3459888: Job Upgrade Status: Variable MODULE_NAME should be overridable and the drush command should also work for themes. There, the MODULE_NAME variable got improved for the upgrade_status job (see https://git.drupalcode.org/project/gitlab_templates/-/merge_requests/237/diffs#43d67bc931cefd24f13e24bc547132e1d13a7ced_600_602). That methodology should be considered to be used in the .create-environment-variables job for general usage.

Before doing that, we need to consider that there are 3 different names that may identify a module/theme/project:

  • GitLab project name from CI_PROJECT_NAME
  • Drupal project name, i.e. the machine name of the module, theme, profile or else. This is the base name of the info.yml file and is required for e.g. drush commands to enable the module or theme ===> This is what we want in MODULE_NAME
  • The directory name, where the project is installed, which can be different if e.g. the composer.json file contains the extra.installer-name property

Maybe we can include MODULE_TYPE in the calculations too. Once we find the info file, it's something like this: export MODULE_TYPE=$(grep "^type:" $MODULE_NAME.info.yml).

If we don't find an info file, we can always use the code that we've had so far as fallback: export MODULE_NAME=${CI_PROJECT_NAME%-*}

We should consider the non-standard case where the info file is _not_ in the root folder. I guess in this case, it will be a best guess among all the info files found (maybe shortest name as submodules tend to be "module_submodule").

Edited by drupalbot
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information