[keycloak-dev] KEYCLOAK-6990 - Allow agnostic environment configuration in theme

[Stian Thorgersen]

I didn't think about containers. You're right it makes it more awkward with
containers. I guess env variables would be best, but would need to figure
out how to test in that case. Maven wouldn't work as we are able to run
tests from IDE as well with an embedded Keycloak server.

Here's my suggestion. In theme.properties allow:

value1=${my_system_property}
value2=${env.MY_ENV_VALUE}

Before loading theme properties create a new properties instance, load it
with system properties as well as environment values (where env variables
are prefixed with env.).

In the theme.properties add properties for default env variables on
different OS. Like so:

linuxHome=${env.HOME}
windowsHome=${env.HOMEPATH}

Then you can check the properties with a runOnServer job rather than with a
custom template. Something along the lines of (pseudo code, not functioning
code):

testingClient.server().run(session ->
   Theme t = ...
   if (System.getenv().containsKey("HOMEPATH"))
     assertEquals(System.getenv().get("HOMEPATH"),
theme.getProperty("windowsHome"))
   else if ....
   ...
   else
     assert.fail("No default env variable found, can't verify"));

See
https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/runonserver/RunOnServerTest.java
for
more info







On Tue, 17 Sep 2019 at 16:21, Vincent Letarouilly <
vincent.letarouilly at gmail.com> wrote:

> Ok I got it working with system properties and it is indeed much simpler
> to test (
> https://github.com/Opa-/keycloak/commit/0fce88947c99c2077827c2ca52514edc7a0cb273
>  )
>
> However it is not clear to me how will I inject system properties when
> running Keycloak inside the official docker container.
> Do you know if I need to override the entrypoint and add some arguments ?
> From what I can see everything given in argument to the
> *docker-entrypoint.sh* will be passed to *standalone.sh* script and will
> end up being passed to the java command with *$SERVER_OPTS* variable.
> Is that correct or is there a simpler solution ?
>
> Best regards
>
> On Tue, Sep 17, 2019 at 11:15 AM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> A simpler option may just be to allow system properties as that would be
>> much simpler to test.
>>
>> On Tue, 17 Sep 2019 at 10:45, Vincent Letarouilly <
>> vincent.letarouilly at gmail.com> wrote:
>>
>>> Hello everyone,
>>>
>>> I started some development on a closed ticket (
>>> https://issues.jboss.org/browse/KEYCLOAK-6990) in order to add the
>>> ability
>>> to load environment variables through theme.properties for custom themes.
>>> I'd need some feedback from you to see if I'm taking the right path here
>>> as
>>> this is my first Keycloak dev and I'm not an expert in Java nor Maven.
>>> This is what I've done so far
>>>
>>> https://github.com/Opa-/keycloak/commit/8f0517d17bd350d22d082516884a757882302d07
>>> but
>>> I'm quite unhappy with the duplication of the maven-surefire-plugin (you
>>> can see that on top of my plugin block, there's an existing
>>> maven-surefire-plugin plugin block) but I did not found other way to
>>> bring
>>> an environment variable into the test context.
>>> If someone could give me some feedback here it'd be very much
>>> appreciated :)
>>>
>>> Regards,
>>> Vincent
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>