Skip to content
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

Use options field for Kaniko from Docker (in fallback case) #1376

Closed
saruman9 opened this issue Mar 28, 2021 · 5 comments
Closed

Use options field for Kaniko from Docker (in fallback case) #1376

saruman9 opened this issue Mar 28, 2021 · 5 comments
Labels
area/config Issues related to the config

Comments

@saruman9
Copy link

Is your feature request related to a problem?
Yes.
Options not inherited from images.app.build.docker.options when builder changed to Kaniko (as fallback for Docker).

Which solution do you suggest?
Inherit options for Kaniko from Docker in fallback case.

Which alternative solutions exist?
Copy images.app.build.docker.options to images.app.build.kaniko.options.

/kind feature

@FabianKramm
Copy link
Collaborator

@saruman9 thanks for creating this issue! They actually should get copied by default, could you provide a sample devspace.yaml where this is not the case?

@saruman9
Copy link
Author

My fault: I don't test the case without the kaniko field.
Example of devspace.yaml, where Kaniko will not use options field from docker:

version: v1beta9
images:
  default:
    image: default
    build:
      docker:
        options:
          target: base
          buildArgs:
            TEST: test
      kaniko:
        snapshotMode: redo
        args:
          - --use-new-run

It's normal, that Kaniko don't run with base target and TEST build arguments, because images.default.kaniko.options is empty. But in cases where Kaniko will works as fallback engine I want to use additional options (snapshotMode, args for example).

@FabianKramm
Copy link
Collaborator

@saruman9 Ah I see, that makes sense yes, we can implement that.

@FabianKramm FabianKramm self-assigned this Mar 30, 2021
@FabianKramm
Copy link
Collaborator

@saruman9 After some consideration, I don't think we should do this. In the case where no kaniko option is present, it makes sense to rewrite the docker config to use as kaniko config, however if an user explicitly defines a kaniko config, the expected behaviour for us is that DevSpace will use that config instead, otherwise its not really possible to override the build options and the config rewritting becomes quite unexpected.

@FabianKramm FabianKramm removed their assignment Apr 6, 2021
@FabianKramm FabianKramm added the area/config Issues related to the config label Apr 6, 2021
@saruman9
Copy link
Author

saruman9 commented Apr 6, 2021

After some days of testing I agree with you, user should explicitly set all settings for Kaniko (include options field). Btw, Kaniko is not suitable for my cases, because it has many issues if used multi-stage builds (see #1383).

Thank you for reviewing my request.

@saruman9 saruman9 closed this as completed Apr 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/config Issues related to the config
Projects
None yet
Development

No branches or pull requests

2 participants