我正在更新一个现有项目，该项目使用名为packs的专有命令行工具来构建一组HTML和Javascript文件。然后，该项目使用Gitlab的CI来运行该工具并将生成的文件部署到Gitlab Pages。
我还更新了packs工具，现在Gitlab CI已被破坏。这是CI日志的相关部分（CI_DEBUG_TRACE设置为true）
$ yarn build
yarn run v1.3.2
warning package.json: No license field
$ packs --build
/usr/bin/env: node
: No such file or directory
当我回到旧版本的packs时，CI部分可以工作。 packs安装了npm。
显然，packs的新版本有问题，然而，对于我的生活，我无法弄清楚它是什么。当我在本地运行它只是工作。我创建了一个基于与我们在CI中使用的相同图像的Docker镜像（节点：8），它也可以完美地工作。
我尝试在本地使用gitlab-runner，它只是不能正常运行（它无法安装本地驱动器，文档太差，他们实际上决定放弃对exec命令的支持）。
我完全彻底陷入困境，除了开始删除包的随机部分之前我怎么知道如何继续，直到找到有问题的行。
罪魁祸首是CRLF线路结束。
我大部分时间都在使用Windows，虽然git将行结尾转换为LF，但是npm却没有。第一个文件 - 该实用程序的index.ts开头
#!/usr/bin/env node<CRLF>
tsc编译为Javascript，但它的默认行为是保持行结尾不变，所以在Gitlab的CI docker容器中，CR就在那里，并且错误实际上是找不到`/ usr / bin / env节点。
告诉tsc生成LF行结尾并确保git不会将它们转换回Windows上的CRLF解决了这个问题。
我仍然不明白为什么在尝试基于与Gitlab相同的图像的docker容器时无法重新创建此问题。