我正在更新一个使用名为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命令的支持）。
我完全彻底陷入困境，除了开始删除包的随机部分，直到找到有问题的行之后，我怎么知道如何继续。
答案 0 :(得分：0)
罪魁祸首是CRLF线的结局。
我大部分时间都使用Windows，虽然git将行结尾转换为LF，但npm却没有。实用程序的第一个文件 - index.ts以
#!/usr/bin/env node<CRLF>
tsc编译为Javascript，但其默认行为是保持行结尾不变，因此在Gitlab的CI docker容器中，CR就在那里，并且错误实际上是`/ usr / bin / env node没找到。
告诉tsc生成LF行结尾并确保git没有将它们转换回Windows上的CRLF解决了这个问题。
我仍然不明白为什么在尝试基于与Gitlab相同的图像的Docker容器时，我无法重新创建此问题。