Add Tugboat configuration to core

Closed duplicate ✨ add Tugboat config.yml Closed: duplicate 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 💬 Umami demo content makes http reponse headers without encoding invalid characters Active

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.

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

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

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

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

juampynr → closed merge request !2279

juampynr → reopened merge request !2279

@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

juampynr → closed merge request !2279

juampynr → reopened merge request !2279

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

Both the previews appeared to work!

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 :)

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.

adding tag.

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

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! ☺️

@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.

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.

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?