Обходной путь из-за отсутствия подстановочных опций аутентификации в Firebase?

Question

Мы используем Google Cloud Build для развертывания конкретных версий нашего приложения по запросу по запросу в GAE, чтобы мы могли делиться разработчиками версий с заинтересованными сторонами, прежде чем запускать их в открытый доступ. В GAE URL-адрес выглядит как http://[VERSION_ID]-dot-[YOUR_PROJECT_ID].appspot.com или https://my-pr-name-dot-projectname.appspot.com

. Мы хотим, чтобы заинтересованные стороны могли просматривать и запускать тесты E2E (включая вход в Firebase), но из-за того, что по сути является поддоменом подстановочных знаков, мыпришлось бы вручную вносить в белый список каждый поддомен в панели управления Firebase в разделе «Авторизованные домены» после развертывания. К сожалению, Firebase не позволяет использовать белый список в стиле подстановочных знаков (например, * -dot-projectname.appspot.com).

Мы обратились в службу поддержки Google, но они подтвердили, что белый список можно создать тольковручную.

Answer 1

Одной из возможностей может быть использование отдельного поэтапного проекта для тестирования PR.

Вы бы использовали белый список для http://[YOUR_STAGING_PROJECT_ID].appspot.com или https://staging_projectname.appspot.com. И вы управляете своим отображением из конкретного PR в промежуточный проект посредством миграции трафика, что может быть сделано программно из ваших сценариев автоматизации PR.

Недостатком будет то, что выэффективно проверять только один PR за один раз. Но это не обязательно все плохо: сериализация проверок PR исключает риск поломок из-за противоречивых изменений, которые каждый проход проходит изолированно .

Существуют также преимущества использования отдельного проекта для целей тестирования. может быть интересен, см. Преимущества реализации сред CI / CD на уровне проекта / приложения GAE по сравнению с уровнем обслуживания / модуля?