代码之家  ›  专栏  ›  技术社区  ›  Zameer Ansari

自动化手动git和构建过程

  •  0
  • Zameer Ansari  · 技术社区  · 5 年前

    我有一个 node.js_server 其中有一个子文件夹,用于 react 前端。以下是目录层次结构表示:

    node.js_server
      - react_frontend_build
    

    现在,要推动任何react前端更改,我需要遵循许多手动步骤:

    1. 在前端git存储库中进行更改
    2. git commit git push 变化
    3. 生成一个 react build &复制生成的文件
    4. 在中粘贴和替换文件 节点。js_服务器 是的 react_frontend_build 文件夹

    现在 节点。js_服务器 更新了 反应_前端_构建 目录

    1. git提交 git push 这些变化让我 continuous delivery 触发管道并部署前端更改。

    对于单个前端的更改,要从编码传播到部署,有这么多手动步骤!

    简而言之,就是git的父存储库( 节点。js_服务器 )的子目录( 反应_前端_构建 )实际上是来自另一个依赖(前端)git存储库的目录(react build)。

    这是一个非常正常的场景,当你在一个 MERN stack 应用程序。所以,我想很多人可能已经看到了这种问题,并可能有解决方案!

    我如何在这里实现整个过程的自动化?

    1 回复  |  直到 5 年前
        1
  •  1
  •   robrich    5 年前

    我也做过类似的事情,通过多次回购协议进入DevOps。这些技术与建立一个常规的、单一的回购DevOps管道没有太大区别。

    我的第一步是构建一个脚本,完成您现在正在做的所有事情——进入另一个项目,运行构建过程,或者传入路径,或者将文件保存到位。

    一旦这个脚本在您的机器上可靠地工作,我们就可以在GitHub Actions这样的构建过程中完成这项工作。这里的神奇之处在于,在构建过程中,你需要查看另一份回购协议的最新副本。在这里,子模块是一个诱人的选择,但可能比必要的更复杂,因为子模块是指向特定提交的链接,需要不断更新。我发现只驱动git cli将另一个repo签出到一个方便的文件夹更容易。魔术酱是确保运行构建的服务帐户至少对另一个repo具有读取权限。如果您的所有构建都使用一个服务帐户,那么它已经使用了:D