Staging instance for D10 Localize port

This is great!!

I can help with the files setup assuming that it'll have the same setup as the newer D10 sites. The needs seem similar to the www port.

I don't see an entry for the "migrate" database in the settings file for the repo. I guess it assumes the same credentials as the "default" database and that the name of the database is "migrate".

It would be great if the above would be added to the "settings.all.php" file and also that Drupal core is brought to Drupal 10 as next steps.

Migrations-wise, I guess once we run them and we swap the sites to the new one, will that be it? Or do they have to be run in any special way?

Updated the IS to add the previous things.

I think this falls into the same blocker as the www.drupal.org migration. We need to put the old database into a new server somehow, with an updated DB version, and that needs infrastructure work.

Once this is done, we just need to add a "helm" folder to it and set the migrations to run, but we are not there yet.

I will communicate it with the team so they are aware of localize being almost ready.

One of the requirements will be to have Drupal core and the modules in use up to date, and preferably on the latest D10 version.

We are meeting later on and I will mention this, but wanted to leave it in the issue.

Steps before going live (some of these are already in the Remaining tasks section)

• Finish the pending work
• The DA will need to do a review and add the infra-related files
• This project needs to be using the new SSO system first, which is not live yet
• Once the above is good, we should try running through the upgrade using staging’s data.
• For that, we need to make sure the upgrade steps are documented and work. So we'll need details on how to set it all up step by step, how and when to run the migrations, etc. This could be in the readme file in https://gitlab.com/drupal-infrastructure/sites/localize.drupal.org

As versions of MySQL greatly differ, database dumps need to be converted somehow before they can be imported into the instance. That is the reason why we will not be running migrations frequently: only once to begin with.

We are doing a general upgrade of MySQL for all Drupal.org production sites in the coming weeks, so this will get better.

This instance might be ready after Drupalcon. In order to share environments during the con with people who cannot or are not used to installing a local environment, we might be using tools like DDEV share (or maybe Drupalpod?).

Please remember to keep the actual data confidential. It is okay to make a public development instance of the site, but do keep it configured as securely as you would a production site.

Thanks for the work on that.

This is then in the same position as the D10 version of www.drupal.org, it needs:
- New SSO system to be in place
- A way to access the D7 database

Once we have these things, we'd be able to try in a dev/stage environment.

Do you need the migrations to be running constantly or is it just a one-off?

Would uploading the DB that you have locally (where I assume migrations where tested against) work? You wouldn’t be able to run migrations but would be able to use the site, right?

Yes, this will be a one-off migration with some downtime as the migration runs.

Before staging is built out, we’ll want to make sure the codebase is fully updated for Drupal core, modules, etc.

We recently launched the Drupal 10 version of API.Drupal.org. We’ll want to make sure everything we learned from that is incorporated into the site build.

We'll want to start a checklist for running and launching the migration, so it can be repeated a few times in staging to find issues, and get an idea of how long it will take. What commands are needed to run the migration? What else is needed?

On these instances you should include either settings.production.php or settings.stage.php

Note that those files are automatically included in the right environment. Anything specific to stage or prod should go there, and if it's sensitive it should be a environment variable via "getenv".

Of particular importance is the activation of the "live" config split, since most languages are disabled on dev environments because too many of them dramatically slows down installation.

Is this something that is set up via the previously mentioned settings file for production? How is that expected to work per environment?

Queues are decoupled from cron, so we need to set up: ...

How often do those queues need to run? Are they one-offs or they need regular running?