@manusa : We still need to change logic to allow overriding of build args. Current behavior in #2994 is to throw exception on if build args with same keys are provided.

Hi @rohanKanojia , do you still need help on this issue ?

@clarenced : Sorry for the late reply, yes it would be nice to get this issue addressed. However, I'm not sure if it's clear enough for you to pick up. I'll check and get back to you.

@rohanKanojia I look at it this weekend and come later if have further questions :)

@clarenced : Have you already started working on it?

@rohanKanojia Not yet, I just read the discussions to have an idea.

Hi @rohanKanojia, It's been a while, do you mind if I pick this up?

@l3002 : 👋 hey, nice to have you back! Sure, you can try this.

thanks @rohanKanojia. I'll get started with it.

Hi @rohanKanojia, Have we decided the precedence of the sources over one another? Because I believe that the following order of precedence (from higher to lower) would be the best possible one for implementing this:

• Build Args specified directly in ImageConfiguration
• Build Args specified via Project Properties
• Build Args specified via System Properties
• Build Args specified via Plugin configuration
• Docker Proxy Build Args detected from ~/.docker/config.json

Let me know what you think about it.

What's the reason for changing the order of precedence stated by Rohan in the description of the issue?

I find it OK that project properties override system properties (although I'm not sure of the side effects especially with Gradle).

Hi @manusa, I think precedence mentioned by Rohan is alright but I also think it would be better if project properties have a precedence over system properties as the user might want to declare more general args as env variables and project specific properties in project properties. I'm not sure about the side effects with build tools, though. I'll check for any anomalies or side effects and update.