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:
- Each branch can maintain their desired PHP compatibility without impacting other Tugboat builds
- New branches will automatically inherit the working Tugboat config from the previous branch
- 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.
- 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.
- 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
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
Comment #5
juampynr commentedBased 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.
Comment #6
juampynr commentedCreated https://git.drupalcode.org/project/drupalorg/-/merge_requests/88 for #3280742: Support Tugboat config file at Drupal core.
Comment #13
juampynr commentedReady 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.
Comment #14
smustgrave commentedMR appears to fail to apply
Comment #16
yesct commentedComment #17
yesct commentedClosed 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
Comment #18
smustgrave commentedSo 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.
Comment #20
q0rban commentedComment #21
q0rban commentedHmm, how do I change the target branch of the MR?@juampynr fixed this.
Comment #22
smustgrave commentedShould a preview link appear anywhere? Know it gets added to PRs in github.
Comment #23
q0rban commentedJuampy (or someone with appropriate access) might need to close and reopen the MR for the Tugboat preview to get built.
Comment #24
smustgrave commentedDo you have access to the tugboat side and can share the preview? just to make sure the config built correctly?
Comment #27
smustgrave commented@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
Comment #30
q0rban commented@smustgrave we needed to rebase the branch, that's why the build was failing. It built correctly now.
Comment #31
smustgrave commentedBoth the previews appeared to work!
Comment #32
gábor hojtsyCan/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 :)
Comment #33
deviantintegral commentedI 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.
Comment #34
nod_adding tag.
This makes a more or less explicit dependency on drush working with HEAD at all time no?
Comment #35
q0rban commentedYes, 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! ☺️
Comment #36
alexpott@q0rban there is a test core way to install from the command line!
php core/scripts/drupal installwill 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.Comment #37
alexpottI think we need to add support for something similar to
--db-url=mysql://tugboat:tugboat@mysql:3306/tugboat --account-name=admin --account-pass=adminto core's install command.Comment #38
q0rban commentedThank 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?