Overriding init.sh results in two init.sh headers in the sls.tgz

[brahms]

What happened?

In an sls repo create a service directory with a file named service/bin/init.sh.

run ./gradlew distTar

Find that the resulting tar has two init.sh files in the tar.

$ tree service/
service/
└── bin
    ├── health-server.py
    ├── init.sh

tar tf build/distributions/....sls.tgz | grep init.sh
.../service/bin/init.sh
.../service/bin/init.sh

What did you want to happen?

I would expect that I would have only one init.sh file in the resulting tar, the one that I put in the folder service/bin/init.sh in the git repo.

I think this plugin should intelligently disable the createInitScript task if the file exists, or the createInitScript task should intelligently use the one on disk rather then creating it.

[ferozco]

Why do you want to overwrite the init.sh?

[brahms]

The reason we override init.sh is so that we can install and apollo manage a java based dropwizard CLI. The custom init.sh script starts up a python service that gets launched instead and gives green/red status back to Apollo so it think's its running. This allows the CLI to be Apollo managed.

[brahms]

If we don't fix this, I just resort to hacking my way around the plugin using tasks.createInitScript.enabled = false

[ferozco]

I don't think its desirable to support custom init.sh and I think there are a couple options you could try instead. For example, could you convert the CLI into to a server which exposes endpoints you can call (perhaps even use witchcraft) instead of wrapping it?

[brahms]

Then the plugin should not allow an invalid tar with two headers to be created by validating that. Either way there probably should be a code change here.