🇪🇸Spain @fjgarlin

Thanks so much! Let's give it a couple of days to see if we no longer hear about reports of this and we can then close this issue.

Thanks for creating the issue and for the detailed information.

We are already checking the "repositories" section of the file in this loop: https://git.drupalcode.org/project/gitlab_templates/-/blob/main/scripts/...

So we could do something like this (untested):

  foreach ($json_project['repositories'] as $key => $repository) {
    if (isset($repository['url']) && $repository['url'] == 'https://packages.drupal.org/8') {
      $packages_drupal_org_found = TRUE;
    }
    if (is_numeric($key)) {
       $non_numeric_key = $repository['name'] . '-' .  $key;  // Append key to ensure the name is unique.
       $json_project['respositories'][$non_numeric_key] = $repository;
       unset($json_project['respositories'][$key]);
    }
  }

Thanks for opening the follow up.

I could bypass the merge train settings but i think it can also wait until it’s fixed in the drupalci_environments issue.

+1 for rebuilding now as many images and as far back in PHP versions as we can.

Thanks for the workaround in #20 in case we need it.

curl -sSLo /etc/apt/trusted.gpg.d/yarn.gpg.asc https://dl.yarnpkg.com/debian/pubkey.gpg

Tried to merge but, as the "Check code" job fails because of the yarn key, we cannot merge.
https://git.drupalcode.org/project/gitlab_templates/-/pipelines/727224

I'll let it sit in RTBC and see if the related issue is fixed again.

Good points. I'll merge it into main, and it'd be create to create a follow up from this in https://www.drupal.org/project/issues/drupal_cms → with the details.

I created https://git.drupalcode.org/project/drupal/-/merge_requests/14549 from the patch in #43.

There were some changes pushed but never made into an MR that are different from the patch https://git.drupalcode.org/issue/drupal-2849620/-/compare/main...2849620...

Setting to needs review to see if the MR is all we need to move forwards with this.

fjgarlin → changed the visibility of the branch 2849620-include-blocked to active.

fjgarlin → changed the visibility of the branch 2849620-include-blocked to hidden.

fjgarlin → changed the visibility of the branch 2849620-optionally-include-blocked-users to hidden.

fjgarlin → changed the visibility of the branch 11.x to hidden.

fjgarlin → changed the visibility of the branch main to hidden.

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

The code looks good. I'd say RTBC based on that, even if DCMS does a 2.0.1 in the coming days.

However, given the test fails in the GTD branches, do we need to report anything in Drupal CMS about this?

Updated issue summary with the new command to re-enable emails after the migration.

After migrating some more projects, it seems that some emails were queued up, and if they were trying to be delivered after the migration, then notifications were sent. We migrated two projects and it only happened in one, and not for all issues.

We've decided to not enable notifications at the end of the automated migration script, and defer that to a separate drush command.

The MR is here: https://git.drupalcode.org/project/drupalorg/-/merge_requests/461/diffs

I wasn't aware that would happen. It sounds like a bug upstream (which they probably won't fix because they are on maintenance-only), but it's not a big deal in this case, I guess, as long as the "changelog" link is clickable.

The question I now have is why the core version is 12.0-dev, when we are only running "next minor". Shouldn't we leave that at 11.x or 11.4.x and have "next major" as "main" which is 12.0-dev

That's how I see too by sticking to the meaning of minor/major. But I'm just unsure yet about how core is using "main". If they are using it for next minors too, then we might need to change, and perhaps even remove, some variants.

I guess next minor and next major can be "main" until a branch for the next minor has been made, and at that point next minor would have 10.4.x and next major "main".

The reason for getting 12.0-dev is because that's what's hardcoded in "main": https://git.drupalcode.org/project/drupal/-/blob/main/core/lib/Drupal.ph...

Merged!

I'd say probably not needed anymore. It's great to see the code AND to be able to test it safely on a per-MR basis.

I can delete that line via MR suggestions, so marking this RTBC. I think it's great also to have the changelog file on the docs site!

Not sure why but https://gitlab-templates-3566118-529820.pages.drupalcode.org/changelog/ appears empty to me.

Given that this file is "the one exception" to the rest of the documentation, I think it's totally fine to add that for rendering purposes.

The previous formatting changes made were to avoid extra manipulation and complex code, and at the same time get a format that works well with any rendering, and that's done.

Sure, I'll make sure that the changelog has that second version. Should we even update the issue title to be that? Happy if you want to change it directly if you think we should.

This is merged now. Thanks!

This is now merged. Thanks!

https://git.drupalcode.org/project/drupalorg/-/merge_requests/456/diffs

Adds as first comment the same as the "automated messages" are when we are working on new issues.

I might have missed this when I came back after the long break in December. Apologies.

Given that the issue at #28 was corrected, this is RTBC. I will merge it tomorrow first thing in the morning.

Some really minor cosmetic changes and then it can go directly to RTBC as all it changed since #30 was the documentation.

How would we go about this on a version of PHP smaller than 8.3? Do we need to rebuild those too or will it just work?

Great! Thanks for following up on this.

Agree that the screenshots and tips might be a good addition. I also suggested to break down the info in 2-3 parts to make it less wordy (same words, just spread differently). NW based on that.

Yeah, it seems that Firefox isn't supporting the fix yet. It shows well in all other browsers after 🐛 composer require text wrapping to the next line under Releases info Active .

That actually worked. So we will need to document this. I'm going to set it to Needs review to get feedback on the changes so far.

Once the current code is validated, we should:
- Move the workaround I did (using _LENIENT_ALLOW_LIST) to GTD d10-plus to the repo/branch
- Document in the variants page the use of "main" and its consequences together with the workaround.

As we are already allowing lenient usage, maybe we can leverage that here for Drupal core somehow.
https://www.drupal.org/docs/develop/using-composer/using-the-drupal-leni... →

I hit merge to test the temp changes job on the merge train and it didn't go through as expected: https://git.drupalcode.org/project/gitlab_templates/-/pipelines/722274

So I'll merge once these are removed.

Silly me! I triggered the pipeline against "main". Proper pipeline: https://git.drupalcode.org/issue/gitlab_templates-3426311/-/pipelines/72...

And no issues! As maintainer, it still builds it at https://gitlab-templates-3426311-issue-77bde373ecf027f1646cc7a4c60a103d.....

This is awesome! Great work in here, this was a long-running issue (+2 years!) and it is amazing that you've managed to figure it all out.

The above might actually be a blocker for this as this is related to "composer" and packaging.

We get an error on the downstream pipeline: https://git.drupalcode.org/project/gitlab_templates_downstream/-/jobs/81...
...drupal/search_api[dev-1.x, 1.39.0, ..., 1.x-dev] require drupal/core ^10.3 || ^11 ...

We ignore the module's composer.json version by default, so this is very likely due to the "drupal/search_api" dependency, and it will be a very common case.

$ composer show drupal/search_api | grep drupal/core
drupal/core ^10.3 || ^11

This is ready for review. Some downstream pipelines: https://git.drupalcode.org/project/gitlab_templates/-/pipelines/722220

Failing job, unrelated to this: 🐛 The following signatures were invalid... when running apt-get update Active

fjgarlin → created an issue.

Note that that's the value which is hardcoded in the 11.x branch: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal.ph...
const VERSION = '11.3-dev';

Re #2, we currently have CORE_NEXT_MINOR: '11.x-dev', so I think the value is what you are suggesting.

This is a POC for our own documentation job.

If you follow the instructions I added in the docs/help/documentation.md you should be able to see the site locally. It works out of the box. The only thing I needed to add was the site_dir for it to be "public" (defaults to "site") but that's even something we can mv after.

For the contrib job, we'd need the variable and depending on the value, install one tool or the other and run the TOOL build command.

Per conversation in #gitlab in the recurrent meeting: https://drupal.slack.com/archives/CGKLP028K/p1769019555502589

@cmlara:

Should that issue be deferred until Zensical releases a 1.0.0?
My understanding is Material is just being considered feature complete for now to allow the resources to go to the new project. 
...
I have my doubts most sites need to run to a new solution that  hasn't fully stabilized yet.

I agree with this, and having the variable suggested in the issue description will be crucial to render one or another solution. The default value might depend on when "Material for MkDocs" stops being supported.

Ready for review.

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

I updated the list.

We have migrated a few DA projects with low impact and low participation (other than us DA) that have helped identify some more bits to improve.

It now checks all types.

fjgarlin → created an issue.

Great!

Should it be available? There are no releases made from "main". There is no "main" version of Drupal. The latest Drupal version is 11, and that branch is there.

Thanks for the changes! I think the whole MR is ready,

I tested on downstream "Key CDN" (https://git.drupalcode.org/project/gitlab_templates/-/pipelines/720282) which will always rebuild the pages site, and now it doesn't which is what we expected. You've also tested all the cases mentioned in the issue description.

RTBC and will merge shortly.

fjgarlin → created an issue.

Merged. It will go with the next deployment.

Before → vs after →

fjgarlin → created an issue.

Re #18 (and my comment at #17). My idea was to detect _PAGES_FORCE_REBUILD being 1, and if the pipeline source is NOT "schedule" or "web", then throw a warning on those cases. But I don't think we need this anymore based on the new rule you added, as the job won't even trigger in those scenarios. We should probably add this to the documentation.

I also added a small suggestion to the MR. NW based on those two things, but it's looking really good.

How about calling it _PAGES_FORCE_REBUILD? But I'd then add a check in the code to only allow this variable via Web UI trigger (or scheduled too), as this shouldn't be a variable permanently committed to the .gitlab-ci.yml file.

At the very least, show a warning if this is the case.

Thanks so much for all the testing and the links, it really helps track the progress.

We created a dedicated endpoint for this in ✨ Provide way to access all projects maintained by a user Active . This is for maintainers. The author of the project should not be relevant.

The endpoint https://www.drupal.org/drupalorg-api/project-maintainers?nid=NID will give you a list of maintainers for the project.

+1 for a tag release.

I think on those cases (create from scratch), the rule:changes code will kick in, because we are watching the whole folder for changes. I think the only case that might not be covered is an existing repo with "docs" where we add the CI file, but even like that, I'm not sure that the job would be triggered. I don't think we need the variable, but we'd need to test two more edge cases I think:
- Existing CI file, no "docs" folder, then we add the "docs" folder together with the "mkdocs.yml" file.
- Existing "docs" folder, no CI file, then we add the CI file.

Based on the results of those two cases, we may or may not need to re-add the check to make sure that "mkdocs.yml" exists.
NW purely based on the testing part as we might not need changes.

Yes, I'd say just go ahead with that approach. GTD project's main purpose is to serve this one for testing, and as you explain above, that might be the quicker/easier way to test this.

The MR here does the same as in ✨ Main should be the top of the list for version selection RTBC . However, I don't know if that's the desired placement with all the "Any ..." and "All ..." options in the dropdown. It would look like this: image →

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

I think that's the best compromise we can get to with what we have. We'll just need to document the process along the way.

Ready for review.

fjgarlin → created an issue.

I was getting the warnings when I updated to PHP8.4, then applied the changes in this MR and I no longer had them.

RTBC. It'd be great to have a new release with this.

fjgarlin → created an issue.

Some small additions are ready in MR444.

The MR above should make "main" be the first option in the dropdown. Ready for review.

This should be in D7 for now. When core issues move to core these will be labels, but for now, we can jump that value to the top.

The api-d7 endpoint shouldn't return data if the issue is migrated.
https://git.drupalcode.org/project/drupalorg/-/merge_requests/443/diffs will adapt the format of the returned information to just include the new link.

This is now deployed to production.

https://git.drupalcode.org/project/entity_reference_revisions/-/merge_re... should be applicable as it was created over a rebased branch. I created a new branch / MR because it was easier than rebasing for this small change. MR45 can be closed in favor of this one.

fjgarlin → changed the visibility of the branch 8.x-1.x to hidden.

My commit: https://git.drupalcode.org/project/gitlab_templates/-/merge_requests/403...

I found what the issue was and the tests are passing now. I think once we deploy this, we should see a big improvement in performance as we shouldn't have that "%_$variable" query anymore.

I did it here https://git.drupalcode.org/project/gitlab_templates/-/pipelines/709164

And the "pages" job didn't trigger, probably because of this condition if: $CI_PROJECT_ROOT_NAMESPACE == "issue" as my triggering would be in the "project" namespace.

The above shows all tests passing. I will merge it so that we have a clean start for working on this issue.

MR to check 2.x current test issues, if any, with the temp code reverted: https://git.drupalcode.org/project/api/-/merge_requests/77/diffs
I'll use this as baseline to compare to the other MR.

🐛 Incorrect manipulation of default revision flag Needs work changes the code around this issue, and neither the patch nor the MR is applicable now.

There are webhooks/crons/sync operations happening in the background when this happens. It should usually be almost instant, but if it isn't, some of the background jobs should catch it and fix it. I checked the contribution record and it seems to be showing the correct project, so I'm closing this. You should be able to assign the credits.

Thanks for the additional checks.

I've also done a new release and set it as default-ref so it includes this issue.

I did several tests here before getting to the final format: https://git.drupalcode.org/issue/gitlab_templates-3566586/-/blob/3566586...

- First set: wasn't rendering links
- Second set: it would most certainly mess up mkdocs output
- Third set: more fail-proof and verbose with links

I have adjusted the CHANGELOG.md file to a format similar to the second one, but with explicit links and escaped characters. I wanted to find a format that would work on both renderers so we wouldn't need to maniputate the file.

New: https://git.drupalcode.org/project/gitlab_templates/-/blob/main/CHANGELO...
Old: https://git.drupalcode.org/project/gitlab_templates/-/blob/ad45690bf3e68...

This should allow mkdocs to render the page nicely (not tested), but we can check it in this issue when we work on it next.

Thanks for the extra testing. The only effective change is the variable not showing in the Web UI form.

Merged.

Agree. I changed the approach to your suggestion, which I think is better. MR is ready.

I thought of that too. Actually, that'd be cleaner.

The errors shown in the nightwatch job are also present in the branch's head (so not introduced by this): https://git.drupalcode.org/project/gitlab_templates_downstream/-/pipelin...

I've done the easiest option (fallback value) in https://git.drupalcode.org/project/gitlab_templates/-/merge_requests/446...

This should at least fix the web UI cases and it should still work, as v20 should still be ok with most Drupal core versions.

Not straightforward as "packages.json > engines.node" is semver. It was created as feature request here https://github.com/nvm-sh/nvm/issues/651 but it doesn't seem to be going anywhere.

Core has ">= 18.0" or ">= 20.0", which are not valid for "nvm".

Options:
- Default to "v20" if no variable and no file are set.
- Read from "core/packages.json" the "engines > node" semver range and extra a valid value. eg: the above two examples should be "v18" and "v20".