🇪🇸Spain @fjgarlin

Doh!! it's just the "echo" 🙈

Ignore that then please and sorry for the noise.

Yup, it's that code there.

I thought we were fixing the path to line up with another automatically generated path. Is that commit not doing that?

The changes look good, but we are also changing the path of the generated files in here, not just creating empty ones.

Marking it RTBC, but can we change the issue summary with the full proposed resolution?

I'm happy either way. On one hand it makes sense two issues as they are easy to isolate and it'll be clear what the changes are, but on the other we only created that new variable because we needed it for this issue, so it's a kind of nice side effect of it.

I'd say let's leave it all in one issue, as it doesnt' really need extra documentation.

I suggested a name change as it was too close to DRUPAL_CORE.

x.y.z - I usually bump "z" for bug fixes and maintenance tasks. And I usually bump "y" for new features/bigger changes.

I was about to include it as part of 1.8.1, as this could be considered a bug, but I also thought that it was a big-enough change to bump the minor. I kind of followed https://project.pages.drupalcode.org/gitlab_templates/help/contributing/...

This is now merged in core. We will need to check if the issue still happens here.

I see you gave it a go at 📌 Migrate project_release_supported_versions table Active .

Merged! Thanks so much for the MR and additional tests.

Images were pushed to our gitlab.com registry as part of 📌 CI: Push to gitlab.com registry instead of dockerhub (avoid rate limit errors) Active .
Core also made the same changes in 📌 CI: Switch drupalci image registry from dockerhub to gitlab.com (mitigate rate limit errorss) Active .

I will merge this now and make it the default for all contrib.

Merged.

MR ready.

fjgarlin → created an issue.

Oh, thanks for letting us know. Hopefully it'll be fixed upstream then.

I've merged the changes. Fixed!

@drumm - for the migration, is it just a table-to-table migration?

Tests are passing now and code looks good. The change will be very similar for contrib.
RTBC.

I think an alias was created somewhere from the old naming to the new naming for chromedriver.

Code-wise, it looks good, and the downstream pipelines are running as expected and pulling the images from the new registry.

Triggering downstream pipelines (there are a few, which is great for testing): https://git.drupalcode.org/issue/gitlab_templates-3516958/-/pipelines/46...

Agree, we can close and keep using MR8 as needed.
Thanks!

Tested with the following CSV:

1,speaker
2,speake
fake-user@fake-email.com,organizer
drumm,volunteer
b_man,organizer

Then ran it for event https://fjgarlin-drupal.dev.devdrupal.org/community/events/midcamp-2025-...
Like this drush drupalorg-event-volunteers 3443832 ./test.csv -v

$ drush drupalorg-event-volunteers 3443832 ./test.csv -v
Adding user 1 as field_event_speakers.                                                                                                                  [notice]
Adding user 2 as field_event_volunteers.                                                                                                                [notice]
Adding user 3064 as field_event_volunteers.                                                                                                             [notice]
Adding user 2689807 as field_organizers.                                                                                                                [notice]
Saving event.                                                                                                                                           [notice]
The following users could not be matched: fake-user@fake-email.com.    

fjgarlin → created an issue.

I don't think we need to show this variable or add it to the documentation. It was a regression from Nightwatch which will likely be fixed. Also, it's an "internal" variable.

The code looks good to me, thanks!

This is a great find!! I'd say let's add the variable to the nightwatch base job regardless of the outcome of that issue.

Do you want to give it a go?

There seems to be a lot of unpredictability in pipelines at the moment.

Yes, dockerhub needs to mark our account in a certain way so we don't hit limits. This was sudden, unexpected and Tim (@hestenet) is dealing with that atm.

Maybe if run-tests.sh has a long future, which I presume it does, we could ask for that enhancement?

At the very least, it's worth opening an issue in core to discuss it.

The changes on this MR look good, so I'm marking it RTBC.

If you could help with this that'd be SO amazing! I've even seen some example where both the components and the "old" format can co-exist (https://to-be-continuous.gitlab.io/doc/ref/php/). If we could achieve that, we wouldn't need to wait for a 2.x effort and this could be started.

If you are willing to help, I'm more than happy to provide background, reviews, etc as you might need them. We could start with the smallest jobs and then start moving up to the more complex ones, and if needed, we could create separate issues to tackle them individually.

I have not done any component yet as I'm working actively on other projects, but I'd love to see this move forward and I'm sure that once we have one or two, rolling more should be easier.

Well, the "linting" jobs do depend on the "composer" job. It's not just a dependency for the "testing" jobs so I'd really say that it's working as designed.

If you'd want to change this behaviour in your pipelines, you could do so with an override like this:

composer-lint:
  needs:
    -"composer (max PHP version)"

Also, I'd say this is a bit of an edge case, where the "current default" is being disabled in favor of a variant, so I don't think we should overcomplicate things in the templates when it is easy to override the setting as shown above.

100% with that suggestion. That way we’ll check both options within a “current” variant.

I left a question in the MR.

Thanks for moving some things around. I left feedback in the MR here. I will merge the MR for 📌 Add Breadcrumbs for Case Studies Active soon.

fjgarlin → made their first commit to this issue’s fork.

Even better. Having both 0 and 1 for the same project is a great way to see that both options should work, even if we're talking of a small set of tests, but the set up, etc is what matters here.

I'd definitely do the directories simplification in a follow-up.

I was going to RTBC but asked a really small question/suggestion in the MR first.

Change the text slightly as it was confusing.

I made some edits to that page to remove references to "Recommended" and adapted the language a bit.

Removed references to "Recommended" after  https://www.drupal.org/project/project/issues/3509485 📌 Remove “recommended” status for releases? Active was merged.

With such a complex MR, it was easier to redo the whole thing than rebasing. New MR: https://git.drupalcode.org/project/drupalorg/-/merge_requests/332

fjgarlin → changed the visibility of the branch 3327584-contribution-records-new-system to hidden.

Rebased with latest changes. Will merge soon when we decide that is a good window to start running the migrations again.

fjgarlin → made their first commit to this issue’s fork.

Thanks for the tests. Yeah, agree with leaving _PHPUNIT_CONCURRENT=0 for the d10-plus branch, so this is RTBC.

We can defo open the issue so at least we know about it. It doesn't need to be top of the list and it can wait until other issues have been dealt with... and of course, anybody could pick it up in between.

Agree to have both usages of _PHPUNIT_CONCURRENT in our branches for testing.

We should definitely document that behaviour of not failing on skipped tests and the option to enable it, either by setting _PHPUNIT_EXTRA or changing the PHPUnit configuration file.

Merged. Thanks!

Happy to touch junit.xml at the beginning of the job.

Left feedback on the MR.

I wonder if this might be related (or be the source of) 🌱 [meta] Known intermittent, random, and environment-specific test failures Active .

Thanks for the changes! Marking RTBC.

Good catch on the colors. Maybe an issue with the nighwatch code where it detects color support? (for example:https://github.com/nightwatchjs/nightwatch/issues/3601)

This can be checked on another issue in any case.

We discussed/reviewed it internally before merging for what is worth. Just forgot to make any comments here.

Two really small nitpicks on the MR.

I'd suggest changing the output slightly and always show it in the job, whether is derived or because it's set by the user.

We could do something like:

Nightwatch version is 3.9.0
- Webdriver: selenium:4444 (w3c: true)

Other than that small change I think it looks good to go. Setting to NW for that small change.

Code-wise it looks good and clean. I've triggered the decoupled pages pipeline here https://git.drupalcode.org/issue/gitlab_templates-3475581/-/pipelines/45...

I see temporary code and I guess you might want to run additional tests, so marking NW based on that, but the code looks good and I am happy with the approach and the way we are keeping BC. Thanks for creating the separate PHPUnit issue, that'll make it easier here, and then there, to review and test.

Scratch that, only used "too late".

I think we can do option 3, but we need to keep BC in case somebody has given values there for their jobs. So we can "null" the values and then derive them in the job, in a way that it matches what we have now, but also do the derivation if the variable is empty, to keep any possible project-defined override.

Option 4: move the variables to .test-variables where we already have variables related to testing?

Isn't https://www.drupal.org/u/grienauer/events-organized → exactly what you want? Linked from your user profile already.

Thanks for the port on the module and on the site configuration for modern Drupal.

Yup, maybe we can use the "main" branch to generate a small documentation site, where we have a page for each branch explaining what each branch is about. Something short but that will be enough to check md files and the pages job.

Once done we can add it to the downstream files in case we do changes to the "pages" job.

Given that you created the two follow-ups above, maybe we can create one for the "pages" documentation files for this project.

I added some minor feedback to MR14.

I think MR257 looks good, but yeah, I totally agree that we if we react to the nightwatch version to set the variable one way or another that'd be amazing.

We should probably try that here in this issue. I was thinking that we could use rules:variables (https://docs.gitlab.com/ci/yaml/#rulesvariables), but I'm not sure what the if conditions will be, so I'm happy for it to be calculated in the .composer-base job where we do all the other variables calculations.

Yup.

The project has a scheduled daily run happening at 10:00am my timezone (https://git.drupalcode.org/project/gitlab_templates/-/pipeline_schedules). Normally, if I'm working on that day, I'll address the issue as soon as I get the notification email as it is just a few minutes' work.

Not a problem. Thank you for being alert on this too.

Awesome, it's great to see we have some more basic tests in the downstream projects.

In the future and when possible, when new issues are reported, we can probably build a test case "somewhere" to replicate that issue and make sure it's fixed.

Thanks for the work here.

MR merged.

fjgarlin → created an issue.

Javascript is weird sometimes... but I'm glad you found the alternative syntax. I think it's cleaner overall and that way we don't need to have the before_script to search/replace code.

So I think that the changes look good.

As mentioned in #2, there is an MR in the private repo where the gitlab runner is managed to add caching to s3.

The patch is this (a bit trimmed down):

--- a/applications/gitlab-runner/gitlab-runner-app.yaml
+++ b/applications/gitlab-runner/gitlab-runner-app.yaml
@@ -29,6 +29,14 @@ spec:
         runners:
           config: |
             [[runners]]
+              [runners.cache]
+                Type = "s3"
+                Path = "drupalcode"
+                Shared = true
+                [runners.cache.s3]
+                  AuthenticationType = "iam"
+                  BucketName = "runners-cache"
+                  Insecure = false            
               [runners.kubernetes]
                 namespace = "{{.Release.Namespace}}"

It needs infra to set "iam" per https://docs.gitlab.com/runner/configuration/advanced-configuration.html... first.

For now I'll postpone this as it really depends on the infra supporting it.

You can comment on that issue. It just hasn't been at the top of the priority tasks to do, and it didn't have much activity.

Won't this need #3387117: Enable distributed caching in GitLab Runner → to be in place for it to actually cache something?

Can we not check if the method exist via javascript hasOwnProperty inside the tests/src/Nightwatch/Tests/downstream-one.js file? That way we won't need the sed nor the before_script.

Untested code:

    browser
      .drupalCreateUser({
        name: 'Downy',
        password: 'Streamer',
        permissions: ['access site reports', 'administer site configuration'],
      })
      .drupalLogin({ name: 'Downy', password: 'Streamer' })
      .drupalRelativeURL('/admin/reports')
      .waitForElementVisible('body', 1000);
    if (browser.assert.hasOwnProperty('textContains')) {
        browser.assert.textContains('h1', 'Reports')
    }
    if (browser.assert.hasOwnProperty('containsText')) {
        browser.assert. containsText('h1', 'Reports')
    }
    browser.assert.noDeprecationErrors();

Versions...

OLD      .assert.containsText(
NEW       .assert.textContains(

fjgarlin → created an issue.

The changes look good. It makes sense to also remove the SKIP_ variables that were using the default value, so it's ok to include it in this MR.

It's the first time that I've seen that type of failure. I'm glad that re-running was enough and I'm hoping that it was a one-off, but defo worth keeping an eye on it in case it happens again.

Deployed to production.

Nothing to be done from the gitlab_templates project, but maybe it can be done at server level, once ready for production use.

https://docs.gitlab.com/administration/gitaly/bundle_uris/
> This feature is not ready for production use.

It could save CPU time.

We don't currently do any git clone operation in the templates.

fjgarlin → created an issue.

Implemented @spicy.werewolf suggestion. Will merge to the theme project and it will go to the site in the next deployment.

fjgarlin → made their first commit to this issue’s fork.

Ported to modern Drupal. The permission is also not used anywhere else in the role's permissions.

The new test and additions look good. RTBC.

Merged.

Looks good.

fjgarlin → created an issue.

Cspell job fixed after the last commit.

You might need to actually ignore the project's dictionary.txt from the cspell configuration.

Ya subiremos el video a youtube y lo añado por aquí también. Gracias @carlos.romero!!

There are warnings in the individual jobs, but those could be addressed separately. If this gets merged then all those jobs will start running on all MRs and will help with getting the code to a better Drupal coding standards/patterns.

fjgarlin → created an issue.

If we are talking margins, then this would be a duplicate of 🐛 Trial Page left padding/margin Active .

Saving credit in this issue.

Per ✨ Grant credit for all closed issues, not just fixed issues Active issue can now be graded on all closed issues.

Merged. Thanks for this one, it's a great feature adding flexibility in the set up.

Thanks for the last changes. I think this is ready. Downstream pipelines run well after the last two commits.
RTBC.