Help fixing jobs for Admin Toolbar

Created on 20 February 2025, about 2 months ago

Hey Fran ! (@fjgarlin)
I hope you've been doing well ! πŸ™‚

Sorry for reaching out straight away, since I'm sure you must be really busy, but I would greatly appreciate your help understanding some issues we've been having with jobs failing for the Admin Toolbar β†’ module.

Problem/Motivation

See the latest build pipeline:
https://git.drupalcode.org/project/admin_toolbar/-/pipelines/427983

We're having multiple issues:

CSPELL:
CSPELL job: https://git.drupalcode.org/project/admin_toolbar/-/jobs/4400942

This had been addressed in πŸ“Œ GitlabCI: Fix CSPELL validation errors Needs review and we've got the file .cspell-project-words.txt which seems to be correct in the repo:
https://git.drupalcode.org/project/admin_toolbar/-/blob/3.x/.cspell-proj...

I haven't looked any further than that, but I don't understand why the file is not picked up anymore by the job in the build....

Could there be anything wrong in the file or any special action to be taken on our side or configuration to be added to the GitlabCI file?

PHPSTAN:
PHPSTAN job: https://git.drupalcode.org/project/admin_toolbar/-/jobs/4400936

I've looked at the logs and we're getting errors that I don't really understand, see for example:

File '/builds/project/admin_toolbar/web/modules/custom/admin_toolbar/BASELINE_PLACEHOLDER' is missing or is not readable.

Or

WARNING: Uploading artifacts as "codequality" to coordinator... 500 Internal Server Error  id=4400936 responseStatus=500 Internal Server Error status=500 token=glcbt-64
WARNING: Retrying...                                context=artifacts-uploader error=invalid argument
WARNING: Uploading artifacts as "codequality" to coordinator... 500 Internal Server Error  id=4400936 responseStatus=500 Internal Server Error status=500 token=glcbt-64
WARNING: Retrying...                                context=artifacts-uploader error=invalid argument
WARNING: Uploading artifacts as "codequality" to coordinator... 500 Internal Server Error  id=4400936 responseStatus=500 Internal Server Error status=500 token=glcbt-64
FATAL: invalid argument                            
Cleaning up project directory and file based variables
00:00
ERROR: Job failed: command terminated with exit code 1

I'm not seeing any errors related with module's code or effective PHPSTAN validation .... I don't really understand what the problem could be here....

Could you please help us take a quick look when you have some time and maybe give us some advice?

I've set up this branch for testing builds in a closed issue fork:
https://git.drupalcode.org/issue/admin_toolbar-3466125/-/commits/3466125...

so if you have any recommendations or advice, I should be able to make changes and get them tested very quickly.

In any case, any feedback, advice or suggestions would definitely be greatly appreciated.
Thanks in advance Fran!

πŸ› Bug report
Status

Active

Component

gitlab-ci

Created by

πŸ‡«πŸ‡·France dydave

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @dydave
  • πŸ‡ͺπŸ‡ΈSpain fjgarlin

    Hey David! I hope this can help you.

    The main reason is that you are pinning the version of the templates to 1.5.10 here https://git.drupalcode.org/project/admin_toolbar/-/blob/3.x/.gitlab-ci.y..., which is fine, but you also need to set an additional variable as mentioned in this page https://project.pages.drupalcode.org/gitlab_templates/info/templates-ver.... You need to set:

    variables:
      _CURL_TEMPLATES_REF: "1.5.10"
    

    So the scripts and the assets downloaded with it match, otherwise you are running some things from 1.5.10 together with some things from the latest version.

    The above might be enough to at least have the templates try to run the expected versions, but might not have some of the many fixes that were fixed between 1.5.10 and the latest version. See the changelog here https://git.drupalcode.org/project/gitlab_templates/-/blob/main/CHANGELO...

    --

    An alternative way of getting the templates to run is to use the defaults in

      - project: $_GITLAB_TEMPLATES_REPO
        ref: $_GITLAB_TEMPLATES_REF
    

    And then to have Drupal 10 as "default" you can customise the DRUPAL_CORE variable as shown in this example: https://project.pages.drupalcode.org/gitlab_templates/info/customization...

    composer:
      variables:
        DRUPAL_CORE: 10.4.1
    

    Éither way should help you with these inconsistencies.

  • πŸ‡«πŸ‡·France dydave

    Super nice Fran! As usual, you rock! 🀩

    Thanks a lot for taking the time to look into this and for all the info you have provided! πŸ™
    It's super helpful!

    At this point, I've only tested just reverting this one line you've pointed, which pins the template version ...
    Really not sure why this was needed in the first place, I'll look into this a bit later (the commits, tickets, etc...).

    Reverting this line allowed all the jobs to go through properly! Thanks a lot Fran!
    https://git.drupalcode.org/issue/admin_toolbar-3466125/-/pipelines/429702

    It seems I'm getting a PHPUnit error now, which is really great!! πŸ˜…
    Looks like we've got some compatibility testing and fixing to do for D11.

    I'm going to keep working on fixing these tests + the config file and let you know if I'm still having any issues ...

    But supposedly, I "should" be able to take it from here!

    Glad to see you're doing great!
    Cheers Fran! πŸ™‚

  • πŸ‡ͺπŸ‡ΈSpain fjgarlin

    Glad to hear that the above got you unblocked!

    The reason for that extra variable is:
    - Short(ish) version: sometimes, as part of the job, we need to download supporting files from the gitlab_templates repo, and if you don't set up that variable, it will download them from the latest (recommended) version. Cspell and phpstan need to download configuration files if the project doesn't have any. So by setting _CURL_TEMPLATES_REF to the same version as ref then you are fully pinning the version of the downloaded files too.
    - Long version: πŸ› _GITLAB_TEMPLATES_REF value in variables needs updating, and provide override variables for Curl Fixed

  • πŸ‡«πŸ‡·France dydave

    Thanks a lot Fran, once again!

    It's super nice of you to take the time to provide more information on the options we could possibly consider πŸ™‚.
    I've learnt quite a lot of things and hopefully will be able to debug a little bit better these types of issues by myself next time πŸ‘.

    I just wanted to give you some feedback on the issue:

    The complete report is here: πŸ“Œ Fix GitLab CI configuration causing jobs to fail with warnings Active

    In the end, I've just reverted back to using the default template, which I think is what we really want:
    We do want to have warnings or errors reported by jobs with deprecation validation, messages on standards changing, etc.... when stable/supported versions change.

    If that doesn't fit the module in the long run, we could still move back to implementing a solution based on the options you provided in this ticket πŸ‘Œ

    Accepted merge request: https://git.drupalcode.org/project/admin_toolbar/-/merge_requests/115

    Module's pipelines: https://git.drupalcode.org/project/admin_toolbar/-/pipelines
    See the change with the stages going from 2 warnings down to 1, as it used to be, before the template version was pinned.

    As far as our module is concerned, the problem can be considered Fixed!! πŸ₯³

    I just wanted to say how impressed I am with the progress that has been made over the last couple of years on the Gitlab CI side and more particularly with all the work you've been pulling though!
    I saw the documentation as well has greatly improved and is really great now: 🀩
    https://project.pages.drupalcode.org/gitlab_templates/

    Thanks again so much for all the great work, patience, kindness and amazing reactivity!
    Looking forward to getting in touch with you again soon!
    Cheers!

  • πŸ‡ͺπŸ‡ΈSpain fjgarlin

    Thanks for the kind words David! It has definitely come a long way, but it wasn't just me, shout out to @jonathan1055 and all the rest of the community who are constantly helping things move forward, both code and documentation!

Production build 0.71.5 2024