Overriding apollo-config.groovy?

[abretaud]

Hello, Is there a proper way to change the content of apollo-config.groovy? I tried mounting my modified version like this:

    volumes:
      - ./apollo-config.groovy:/apollo/apollo-config.groovy

or like this:

    volumes:
      - ./apollo-config.groovy:/var/lib/tomcat8/webapps/ROOT/WEB-INF/classes/apollo-config.groovy

But first one fails probably because apollo would need to be rebuilt, and with second one the war fails to deploy.

I'm trying to do it to use the REMOTE_USER auth.

(no hurry on this, I'm leaving now)

[hexylena]

For us, it has to be done at build time because we load extra JBrowse plugins in and WAR deployment is scary enough that I'll just follow the standard build instructions ;) Interesting that the deploy fails in second case.

E.g. https://github.com/erasche/docker-apollo/tree/cpt I maintain a separate branch with my organisation's customised copy of Apollo. We use extra plugins and various hacks.

[nathandunn]

@abretaud I think what Eric is advocating is probably the best, but I'm going to leave this open to think about it. I wonder if docker should detect if there is a custom-apollo-config.groovy (which is not source-managed), which if it exists it copies into docker into apollo-config.groovy instead.

Let me know what you think.

[abretaud]

Thanks for the link, some things look very interesting for me there :) I may maintain a separate branch too in the end, but anyway, see #13 for a possible solution to this issue. The deploy fails in the second case because when deploying the war at startup, it first checks if the ROOT dir already exists and tries to erase it before extracting the ROOT.war (and fails because of the mount point) (and happy 2017 😄 )

[hexylena]

The deploy fails in the second case because when deploying the war at startup, it first checks if the ROOT dir already exists and tries to erase it before extracting the ROOT.war (and fails because of the mount point)

This is easy! we just unpack the war ahead of time. Then no unpacking happens, and you can mount volumes over it. If you have time, test this (jar xvf apollo.war), if not I'll get around to it next month or so.

I wonder if docker should detect if there is a custom-apollo-config.groovy

:-1: on this, would be unnecessary complication, we can solve this other ways. Too much magic for my taste ;)

[abretaud]

This is easy! we just unpack the war ahead of time. Then no unpacking happens, and you can mount volumes over it. If you have time, test this (jar xvf apollo.war), if not I'll get around to it next month or so.

Hum, I remember having this idea at some point, but I can't remember if it failed or if I just forgot to test it... I'll have a look

[hexylena]

If it failed, it would be quite interesting. let me know how it goes!

[abretaud]

Ok, unpacking the war works fine! I'll update #13 soon

[abretaud]

Done updating #13! I also pushed my branch there in case you're interested: https://github.com/abretaud/docker-apollo/tree/bipaa

[hexylena]

Awesome! Thanks for sharing. Will try and get some variation on this added to other images.

Den fre. 13. jan. 2017, 14.22 skrev Anthony Bretaudeau < notifications@github.com>:

Done updating #13 https://github.com/GMOD/docker-apollo/pull/13! I also pushed my branch there in case you're interested: https://github.com/abretaud/docker-apollo/tree/bipaa

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/GMOD/docker-apollo/issues/12#issuecomment-272453808, or mute the thread https://github.com/notifications/unsubscribe-auth/AAb_u68QIraNGwXDgo2MjHsMFN7hhVkmks5rR4iVgaJpZM4LUJkn .

[nathandunn]

Let me know if this need to be re-opened.

[nathandunn]

(or just re-open it)