小编kol*_*nte的帖子

我们正在将动态部署添加到测试环境中，在该环境中每个合并请求都有自己的url，以便能够为不是开发人员的人手动进行前端测试。

这些实例docker-compose与GitLab CI / CD 一起部署，效果很好。

现在，合并请求合并后，我现在想自动关闭这些实例。

到目前为止，我还有额外的步骤可以手动关闭测试实例：

deploy-dynamic-down:
  tags:
    - docker
  stage: deploy-dynamic
  script:
   - docker-compose down
  when: manual

这很好用，但是需要手动步骤，几乎肯定会不时地将其遗忘，这需要我们时不时地清理转轮。

因此，我的问题是：仅当合并请求合并时，我才能触发此管道步骤运行吗？

我不能仅将此管道限制为某些分支，例如master或develop，因为我们并不总是仅对这些分支创建合并请求。我不知道合并请求将预先定位到哪个分支。

我知道您可以将推送通知发送给已安装pwa的用户。但是，这始终需要一台发送该通知的服务器，并且最终用户设备也处于联机状态才能接收并显示该通知。

我想知道是否有一种方法可以“安排”稍后显示的推送通知，例如Android上可以实现事件提醒之类的功能，而无需连接互联网。

我有一个 vue.js SPA，我想将其部署在不同的服务器上，而无需为每次部署重新编译前端。SPA 连接到后端，其 URL 未知。有没有一种方法可以在运行时动态地告诉前端后端在哪里？

许多文章和论坛主题建议针对不同的环境使用不同的配置文件，并在构建时构建它们，但这对我来说不是一个选择，因为我根本不知道构建时前端/后端将部署在哪里。

编辑：该项目是一个开源项目，因此我无法真正假设人们将如何部署它。我总是“假设”它将部署在一个单独的子域上，前端可以访问/，后端可以通过代理访问/api，因为这就是我设置服务器的方式。然而，我见过人们将 api 部署在与前端完全不同的子域（有时甚至使用不同的端口）或子路径上，甚至是两者的混合上。

到目前为止我考虑过的事情：

1. 将配置放入 a 中，conf.js然后通过或类似的方式公开后端 url ，并从标签window.config.backendUrl中加载该文件index.html<script>
2. 与 1. 有点相似：将配置放入 a 中config.json，并在应用程序加载后向其发出获取请求，然后将其结果公开在window.config.backendUrl
3. <script>window.config.backendUrl = 'http://api.example.com'</script>在我的index.html.
4. 使用定制的 Web 服务器（基于express或类似）为前端提供服务，该服务器解析 env 或不同的配置文件，然后<script>动态创建来自 3. 的标签
5. 始终“假设”后端将在哪里进行某种列表的工作，例如“首先查看/api然后./api查看api.current-host.com等等”。
6. 将前端与后端捆绑在一起——这样我就总是“知道”后端相对于前端的位置。

然而，所有这些选项在我看来都有点老套，我认为必须有更好的方法。

我最喜欢的是第三个选项，因为恕我直言，它是可配置性和性能之间的最佳权衡。