# Question about "gatling.sh", defining binaries folder and "inc\_compile.zip"

**URL:** https://community.gatling.io/t/question-about-gatling-sh-defining-binaries-folder-and-inc-compile-zip/5086
**Category:** Gatling (Open-Source)
**Created:** [June 23, 2019, 6:40am UTC](https://community.gatling.io/t/question-about-gatling-sh-defining-binaries-folder-and-inc-compile-zip/5086 "2019-06-23T06:40:21Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![Siegfried\_Goeschl](https://avatars.discourse-cdn.com/v4/letter/s/3d9bf3/32.png) [@Siegfried\_Goeschl](https://community.gatling.io/u/Siegfried_Goeschl)
#### Post date: [June 23, 2019, 6:40am UTC](https://community.gatling.io/t/question-about-gatling-sh-defining-binaries-folder-and-inc-compile-zip/5086/1 "2019-06-23T06:40:21Z")

</div>

HI folks,

looking at deploying Gatling 3.1.2 in the cloud and currently playing around with Docker & Jenkins 🙂

One approach I’m currently looking into is to have an installation of Gatling in “/usr/share/gatling” and start the Gatling test over Jenkins (command line)

- /usr/share/gatling would be a read-only folder
- I’m setting the binaries folder using “-bf /somepath//target/”

But it is now working properly- an “inc\_compile.zip” is still created in $GATLINGHOME/target

Looking at “ZincCompiler.scala” it won’t be working as expected

`val cacheFile = (GatlingHome / "target" / "inc_compile.zip").toFile`

Some thoughts along the line

- IMHO this is not the expected behaviour and will not allow to run from a read-only installation safely

- “inc\_compile.zip” is updated by each test run

- Of course I can symlink to something like “var/gatling” but I can not guarantee that no parallel execution take place thereby corrupting the file

Thanks in advance,

Siegfried Goeschl