0

I have shell script as following -

enter image description here

Since gradlew is on project root, it is invoked as ../gradlew clean which is one level above the backend_test.sh file -

enter image description here

However Gitlab ci job fails with following error -

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

If I move backend_test.sh also on root level and update shell file to invoke gradlew as ./gradlew clean then there is no error. What am I doing wrong when backend_test.sh is not on root level?

Update:

Running shell locally i.e. ./backend_test.sh gets me following error -

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'.

Why is build.gradle looked up in test-runner folder even though it is is on same level as test-runner?

Tarun
  • 3,456
  • 10
  • 48
  • 82
  • Looking at the directory tree I'm not sure why you think that gradlew `is one level above the test-runner folder` - it's in the same folder. – Arkadiusz Drabczyk Dec 24 '20 at 14:04
  • I believe error is clear, is not able to find `gradlew` on your script's 21st line. May be give it a try to give an absolute path while running it and it should fly then IMHO. – RavinderSingh13 Dec 24 '20 at 14:05
  • Wrong wordings @ArkadiuszDrabczyk, gradle wrapper is one level above the shell script. Have updated qs. – Tarun Dec 24 '20 at 14:09
  • @RavinderSingh13 project is not to be run only on my machine and hence absolute path does not help. `../gradlew` is supposed to look at parent folder where gradle wrapper is available. – Tarun Dec 24 '20 at 14:11
  • @Tarun, ok, so you mean path of this file is not fixed? If yes then we could run a find command in shell get its path and then do your operation with complete path, please do let me know what you think on this one, cheers. – RavinderSingh13 Dec 24 '20 at 14:13
  • gradle wrapper path is fixed from project root and hence I used `../gradlew ` to get to root of project, which obviously does not work and I want to know why?. – Tarun Dec 24 '20 at 14:17
  • @Tarun, please bear with me I am not an expert of your tool/language. but how about `cd .. && ./gradlew clean.....your command from here` which means go one level above and then run the script, kindly do let me know if this helps you. – RavinderSingh13 Dec 24 '20 at 14:20
  • Same error with `cd .. && ./gradlew` – Tarun Dec 24 '20 at 14:29
  • @Tarun, then let us check what's the current path of your script before running this, do like `cd .. && pwd && ./gradlew` which should print current path too, let me know what it prints. – RavinderSingh13 Dec 24 '20 at 14:31
  • This is what I get - `+ cd .. + pwd + ./gradlew clean backendTestByGroup ./test-runners/backend_test.sh: line 22: ./gradlew: No such file or directory` – Tarun Dec 24 '20 at 14:35

1 Answers1

1

All relative paths are evaluated relatively to the current working directory. If you are using a shell, the working directory is often shown in your shell prompt. There is no link between your working directory and the directory of the currently processed file. This behavior explains all of your problems:

Since gradlew is on project root, it is invoked as ../gradlew clean which is one level above the backend_test.sh file -

On CI servers, all processes are usually invoked using the root directory as working directory (I'm not sure about GitLab CI, but I guess that it behaves this way, too). Now ../gradlew will be evaluated relatively to your root directory, which won't work, since it searches for gradlew in the parent directory of whatever GitLab CI uses as a temporary folder. You can check this behavior by locally navigating a shell to your project directory and then invoking test-runners/backend_test.sh, it should result in the same error.

If I move backend_test.sh also on root level and update shell file to invoke gradlew as ./gradlew clean then there is no error.

Well, of course this works as long as the script will be invoked from your project directory, which is the default on CI servers, as we already noticed. Locally you can simply navigate to your project directory and just invoke backend_test.sh.

Running shell locally i.e. ./backend_test.sh gets me following error

Well, now we got the same problem the other way around. Your script can find ../gradlew and Gradle is invoked, but sadly, Gradle will evaluate the working directory to find the relevant build.gradle file. But now the working directory is inside your test-runners folder and Gradle will search this folder for a build.gradle file. If there is no build.gradle file inside that folder, Gradle does not care at all, instead it just assumes there is an empty build.gradle file. Now Gradle uses this (empty) project to run the build, but since there is no task clean in the (empty) project, Gradle fails.

Lukas Körfer
  • 13,515
  • 7
  • 46
  • 62
  • Is there no way to keep files in test-runners folder and not have them on root where gradle files are available? I have multiple sh files on test-runners and having them on root level makes project impression bit bloated and not well organized. Thanks for taking time to respond on vacations days. – Tarun Dec 25 '20 at 11:11
  • 1
    You can keep the file inside the `test-runners` folder and change `../gradlew` to `./gradlew` in your script files. This way it should work on CI. Locally you would need to invoke the scripts from the project directory (navigate there and call `test-runners/backend_test.sh`). – Lukas Körfer Dec 25 '20 at 11:19
  • Alternatively you could edit your script files to [automatically change the working directory to the directory of the script file](https://stackoverflow.com/questions/3349105/how-to-set-current-working-directory-to-the-directory-of-the-script-in-bash). – Lukas Körfer Dec 25 '20 at 11:24
  • `./gradlew` did the trick. Fun fact: IDEA changed `./gradlew` to `../gradlew` when I moved sh files to `test-runners` folder. – Tarun Dec 25 '20 at 12:28
  • Yeah, sometimes those automatic refactorings get a little bit out of hand. – Lukas Körfer Dec 25 '20 at 12:30