Skip to content

<platform> configuration should be configurable with system properties #2742

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
chanseokoh opened this issue Sep 3, 2020 · 6 comments · Fixed by #3526
Closed

<platform> configuration should be configurable with system properties #2742

chanseokoh opened this issue Sep 3, 2020 · 6 comments · Fixed by #3526

Comments

@chanseokoh
Copy link
Member

chanseokoh commented Sep 3, 2020

For example, -Djib.from.platforms=... list of platforms ....

Note that architecture and os are required sub-properties. Need to think about the format. Also consider #2471.

@LeaTaka
Copy link

LeaTaka commented Aug 7, 2021

Any progress on this?

I like to decouple the choice of platform from my app.
So for example this would be handy -->
-Djib.from.image=arm32v7/adoptopenjdk:11-jre-hotspot
-Djib.from.platforms.platform.architecture=arm
-Djib.from.platforms.platform.os=linux

@chanseokoh
Copy link
Member Author

If your main goal is to decouple the platform settings, then for now, you can easily parameterize them through Maven properties with default values.

@LeaTaka
Copy link

LeaTaka commented Aug 11, 2021

Hey, thanks for your reply!

I use parameterization for most settings, however for the deeply nested platform settings like 'architecture' and 'os', I can't get it to work. In my example below I'll show you what works and what doesn't.

POM settings that work well:

<from>
  <image>arm32v7/adoptopenjdk:11-jre-hotspot</image>
  <platforms>
    <platform>
      <architecture>arm</architecture>
      <os>linux</os>
    </platform>
  </platforms>
</from>

Above settings replaced by parameters in mvn command:
-Djib.from.image=arm32v7/adoptopenjdk:11-jre-hotspot (THIS WORKS)
-Djib.from.platforms.platform.architecture=arm (DOESN'T GET PICKED UP)
-Djib.from.platforms.platform.os=linux (DOESN'T GET PICKED UP)

Maybe I got the explanation in the docs wrong --> (i.e. -Djib.parameterName[.nestedParameter.[...]]=value), any ideas?

@chanseokoh
Copy link
Member Author

chanseokoh commented Aug 16, 2021

@LeaTaka so what I was talking about as a workaround was to use standard Maven features to accomplish the same effect of using the built-in Jib system and Maven properties. For the built-in Jib properties, our code reads system and Maven properties like this, but as you observed, this isn't defined for the <platform> configurations yet. So, what you can do with standard Maven features is like:

<properties>
  <!-- Define Maven properties. These are arbitrary Maven properties, so you can name them however you want. -->
  <jib.platform-arch>amd64</jib.platform-arch> <!-- most likely the default value you want to use -->
  <jib.platform-os>linux</jib.platform-os>
</properties>

...

   <!-- Jib configuration -->
   <from>
     <image>arm32v7/adoptopenjdk:11-jre-hotspot</image>
     <platforms>
       <platform>
         <architecture>${jib.platform-arch}</architecture>
         <os>${jib.platform-os}</os>
       </platform>
     </platforms>
   </from>

Then, when you run Jib, by default the platform will be linux/amd64. If you want to override the Maven properties, you'd do, e.g.,

$ ./mvnw -Djib.platform-arch=arm jib:build

@StringKe
Copy link

How to set up multiple platforms?

-Djib.from.platforms[0].os=linux -Djib.from.platforms[0].architecture=amd64 -Djib.from.platforms[1].os=linux -Djib.from.platforms[1].architecture=arm64

or

-Djib.from.platforms.os=linux -Djib.from.platforms.architecture=amd64 -Djib.from.platforms.os=linux -Djib.from.platforms.architecture=arm64

@chanseokoh
Copy link
Member Author

chanseokoh commented Jun 27, 2022

@StringKe it's a list property. For example, -Djib.from.platforms=linux/amd64,linux/arm64.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants