Problem/Motivation

Based on this comment by @drumm at #3200622-3: Have Drupal core Tugboat previews default to using Umami profile (instead of standard), we can add a .tugboat/config.yml file to Drupal core in order to manage Tugboat configuration more effectively.

At the moment Tugboat configurations are hosted at https://github.com/TugboatQA/drupalorg/tree/master/drupal. The way this works, it should pick up the configuration file right away if it exists. Details at https://git.drupalcode.org/project/drupalorg/-/blob/7.x-3.x/drupalorg/in....

Drupal core's current Tugboat QA integration requires a bit of custom code both in Drupal.org Customizations and with a separate repository hosted on GitHub that contains the configuration for Drupal core versions, as necessary. When a new core development branch is created, the Tugboat QA support team often needs to create a new branch here before Tugboat previews will build correctly for the new branch. For the most part, these separate configs are identical, with PHP versions being the primary difference.

It would be ideal for these Tugboat config files to live inside of the Drupal core repository itself. The benefits of this are:

  1. Each branch can maintain their desired PHP compatibility without impacting other Tugboat builds
  2. New branches will automatically inherit the working Tugboat config from the previous branch
  3. The Drupal.org Customizations module will be able to remove custom code that is used to pull the Drupal core config from the separate GitHub repository.
  4. On a related note, currently if a Tugboat Base Preview needs to be created, it requires the execution of a custom drush command in d.o prod, which means that someone on the Drupal Association Engineering team needs to execute this. If the config lived in the repository, the Tugboat QA support team could perform these operations without needing to inconvenience the DA team.
  5. If PHP compatibility is being worked on in an MR, that branch can modify the config.yml to change to the newer PHP version. This would allow for manual QA of the new PHP version in Tugboat previews prior to the merge occurring.

, so that each branch can customize as necessary, and so that additional logic isn't needed inside of the drupalorg module to create

Proposed resolution

Add this config.yml file to the 11.x branch, and then backport to other active branches from there.

Some discussion around this change can be found in Drupal slack.

Issue fork drupal-3280730

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

juampynr created an issue. See original summary.

juampynr’s picture

Based on https://git.drupalcode.org/project/drupalorg/-/blob/7.x-3.x/drupalorg/in..., it seems that we need to make a small adjustment at drupalorg module. Looking into this.

juampynr’s picture

Status: Active » Needs review

Ready for review.

If we add it to all branches from 7.x to 9.3.x then we could get rid of this repository: https://github.com/TugboatQA/drupalorg/tree/master/drupal.

smustgrave’s picture

Status: Needs review » Needs work

MR appears to fail to apply

Version: 10.0.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

yesct’s picture

Issue summary: View changes
yesct’s picture

Closed duplicate #3453285: add Tugboat config.yml from @q0rban .

Seems like the next step here is to get a passing MR.

ps. I was familiar with this issue, from a little work I did on #3442674: [upstream] Umami demo content makes http reponse headers without encoding invalid characters

smustgrave’s picture

Issue summary: View changes

So for here would need an MR that's pointed to 11.x and up to date, last MR is about 1100 commits behind. I feel I saw those Umami failures on another ticket and the MR just needed to be rebased.

q0rban made their first commit to this issue’s fork.

q0rban’s picture

Status: Needs work » Needs review
q0rban’s picture

Hmm, how do I change the target branch of the MR?

@juampynr fixed this.

smustgrave’s picture

Should a preview link appear anywhere? Know it gets added to PRs in github.

q0rban’s picture

Juampy (or someone with appropriate access) might need to close and reopen the MR for the Tugboat preview to get built.

smustgrave’s picture

Do you have access to the tugboat side and can share the preview? just to make sure the config built correctly?

smustgrave’s picture

Status: Needs review » Needs work

@juampynr thanks for doing that

https://mr2279-7mhjiuftaaibazrbeau3ucojobodzhdu.tugboatqa.com/
https://mr2279-pjeggdpmrvywzrlbvyajpptceh5bqrqn.tugboatqa.com/

Not sure why 2 links get generated but based on tugboat for my work these should not change with this MR.

But seems both previews failed to build

q0rban’s picture

Status: Needs work » Needs review

@smustgrave we needed to rebase the branch, that's why the build was failing. It built correctly now.

smustgrave’s picture

Status: Needs review » Reviewed & tested by the community

Both the previews appeared to work!

gábor hojtsy’s picture

Can/will tugboat maintain the same config file format / keys, etc. as long as the respective Drupal core versions are supported? I guess that is a key question if we put it into core, that is impossible to retroactively change :)

deviantintegral’s picture

I don't think we've ever broken compatibility on the config.yml file. We've added optional keys over time, but never removed them.

However, I will say that the state of the whole ecosystem is such that it's pretty challenging to build a project that is years out of date. Most commonly, we see things like apt packages going away, or URLs changing, such that you have to do some edits to get an old project going. We'll even see this soon with Drupal, where if Tugboat (or any CI) was installing composer 1 it will no longer work without upgrading to Composer 2.

nod_’s picture

adding tag.

This makes a more or less explicit dependency on drush working with HEAD at all time no?

q0rban’s picture

This makes a more or less explicit dependency on drush working with HEAD at all time no?

Yes, that is true… and that is already the case with the current Tugboat integration for core. We've had it working this way for the past several years, and it's not been a problem. I'm open to suggestions if there are other ways to install Drupal from scratch programmatically! ☺️

alexpott’s picture

Status: Reviewed & tested by the community » Needs work

@q0rban there is a test core way to install from the command line! php core/scripts/drupal install will install Drupal. In the past when we've had dependencies on drush we've had problems so I'd be loathed to add an explicit dependency.

alexpott’s picture

I think we need to add support for something similar to --db-url=mysql://tugboat:tugboat@mysql:3306/tugboat --account-name=admin --account-pass=admin to core's install command.

q0rban’s picture

Thank you @alexpott!

Since we are already using drush for the current Tugboat preview integration, do you think it would acceptable to continue to use it until such a time as there is support for #37 in core's install command? Or do you see that as a blocker to this task?

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.