feat(kaniko): possibility to manually specify images

[v0lkc]

Changes

We'd like to manually specify the set of images kaniko shall build and don't use the autodiscovery magic. For this purpose I'm introducing a new parameter containerMultiImageBuildImages to kanikoExecute which can be used to map docker image names to the local path where the Dockerfile can be found.

  kanikoExecute:
    containerMultiImageBuildImages:
      'my-image': 'this/can/be/in/a/subfolder/Dockerfile'
      'another-image': 'this/can/be/another/subfolder/Dockerfile'

• [x] Tests
• [x] Documentation

[v0lkc]

/it

[loewenstein]

We've had a similar case with cnbBuild and came up with "simply" calling it multipleImages, maybe it makes sense to align naming of the two steps for producing container images. A bit special maybe, but still worth considering imho, we allow basically the whole set of inputs for a single image to be provided per image.

[v0lkc]

Valid point, though it sounds like we'd likely end up in a more intense refactoring of the kanikoExecute interface. Most of the current buildoptions would get obsolete / need to be deprecated and I would rather prefer to do this in a different PR.

[loewenstein]

Well, first and foremost I wanted to hint at the possibility to go with a consistent naming, by choosing multipleImages following the precedent from cnbBuild.

Regarding the potential fallout of approaching a full refactoring that supports all config also for multiple images, maybe someone from @SAP/jenkins-library-cnb wants to chime in? I think we did not have to deprecate options. Instead, we still support single image build with configuration in the root, we just additionally support multiple runs. Not sure how much refactoring this took.

[modulo11]

What we did is merge the incoming configurations (single and multiple) into a common slice/structure and internally treat them as the as before.

[phil9909]

Before we start discussing implementation details, we should get the general buy-in from @OliverNocon as he dismissed a similar proposal by @c0d1ngm0nk3y and myself earlier (PR https://github.com/SAP/jenkins-library/pull/3452) in favor of the autodiscovery. But he seems to be open for discussion:

If there was a need to enhance based on user feedback, one could always consider enhancing the capabilities. Source; https://github.com/SAP/jenkins-library/pull/3443#discussion_r789718860

But I agree that it would be good to implement it consistent to how we have implemented it in cnbBuild for well consistency within Piper. I guess it is also provides maximum flexibility to the users, while reducing duplication. See example in the documentation

[OliverNocon]

Before we start discussing implementation details, we should get the general buy-in from @OliverNocon as he dismissed a similar proposal by @c0d1ngm0nk3y and myself earlier (PR #3452) in favor of the autodiscovery. But he seems to be open for discussion:

If there was a need to enhance based on user feedback, one could always consider enhancing the capabilities. Source; #3443 (comment)

But I agree that it would be good to implement it consistent to how we have implemented it in cnbBuild for well consistency within Piper. I guess it is also provides maximum flexibility to the users, while reducing duplication. See example in the documentation

thanks for quoting me on this :-)

time moved on and yes, we see now that there is more demand on this. Thus, generally from my POV one could go ahead and allow for a capability to define dedicated image names. I am not sure though if this would span to other steps as well due to possible dependencies.

@anilkeshav27 what do you think?

[OliverNocon]

Valid point, though it sounds like we'd likely end up in a more intense refactoring of the kanikoExecute interface. Most of the current buildoptions would get obsolete / need to be deprecated and I would rather prefer to do this in a different PR.

multipleImages in cnbBuild looks to me semantically different - at least for now, since e.g. buildpacks wouldn't be relevant for kanikoExecute.

From that perspective I would be okay to move on with the current suggestion. Alternatively, one could consider also using a []map[string]interface{} instead of the current suggestion - to at least be prepared.

Opinions?

[v0lkc]

/it

[OliverNocon]

there is more stakeholder feedback available which indicates that a solution closer to what is done inside cnbBuild is favourable:

          DOCKERFILE: app/Dockerfile
          CONTEXT: ./xyz/build
          IMAGE_NAME: xyz
          HELM_VALUES_FILE: charts/values.yaml

Thus, guess to start with, parameters for following values could make sense:

• dockerfile path
• context
• image name

[github-actions[bot]]

Thank you for your contribution! This pull request is stale because it has been open 60 days with no activity. In order to keep it open, please remove stale label or add a comment within the next 10 days. If you need a Piper team member to remove the stale label make sure to add @SAP/jenkins-library-team to your comment.

[github-actions[bot]]

Pull request got stale and no further activity happened. It has automatically been closed. Please re-open in case you still consider it relevant.

[OliverNocon]

re-opening since this is still a topic which we should address ...

[github-actions[bot]]

Thank you for your contribution! This pull request is stale because it has been open 60 days with no activity. In order to keep it open, please remove stale label or add a comment within the next 10 days. If you need a Piper team member to remove the stale label make sure to add @SAP/jenkins-library-team to your comment.

[github-actions[bot]]

Pull request got stale and no further activity happened. It has automatically been closed. Please re-open in case you still consider it relevant.

[maximilianbraun]

@OliverNocon can we revive the PR?