shell不识别渐变包装器。

Question

我有shell脚本如下-

​

​

因为gradlew位于项目根上，所以它被调用为../gradlew clean，它比backend_test.sh文件高出一个级别-

​

​

但是Gitlab ci的工作失败了，有以下错误-

./test-runners/backend_test.sh: line 21: ../gradlew: No such file or directory

如果我也在根级别上移动backend_test.sh并更新shell文件以调用gradlew作为./gradlew clean，那么就没有错误。当backend_test.sh不在根级时，我做错了什么？

更新：

在本地运行shell，即./backend_test.sh会让我遵循以下错误-

Configure project : 
Evaluating root project 'test-runners' using build file 
'/Users/tarunkumar/dev/git/system-test/test-runners/build.gradle'.
All  projects evaluated.

FAILURE: Build failed with an exception.

* What went wrong:
Task 'clean' not found in root project 'test-runners'.

为什么build.gradle在test-runner文件夹中查找，即使它与test-runner的级别相同

Answer 1

所有相对路径相对于当前工作目录进行评估。如果使用的是shell，则通常在shell提示符中显示工作目录。工作目录与当前处理文件的目录之间没有链接。这种行为解释了所有的问题：

，因为gradlew位于项目根上，所以它被调用为../gradlew clean，它比backend_test.sh文件高出一个级别-

在CI服务器上，通常使用根目录作为工作目录调用所有进程(我不确定GitLab CI，但我猜它的行为也是这样的)。现在，../gradlew将相对于根目录进行评估，而根目录不起作用，因为它在gradlew CI作为临时文件夹使用的父目录中搜索GitLab。您可以通过在本地导航一个shell到您的项目目录，然后调用test-runners/backend_test.sh来检查此行为，这将导致相同的错误。

--如果我也在根级移动backend_test.sh并更新shell文件以调用gradlew作为./gradlew clean，那么就没有错误。

当然，只要脚本将从您的项目目录调用，这是CI服务器上的默认设置，正如我们已经注意到的那样，这是可以工作的。在本地，您只需导航到您的项目目录，只需调用backend_test.sh。

在本地运行shell，即./backend_test.sh将获得以下错误

现在我们遇到了同样的问题。您的脚本可以找到../gradlew并调用Gradle，但遗憾的是，Gradle将对工作目录进行评估，以找到相关的build.gradle文件。但是现在工作目录在您的test-runners文件夹中，Gradle将在这个文件夹中搜索一个build.gradle文件。如果该文件夹中没有build.gradle文件，Gradle根本不关心，而只是假设存在一个空的build.gradle文件。现在Gradle使用这个(空)项目来运行构建，但是由于(空)项目中没有任务clean，所以Gradle失败了。