migrate to upstream kaniko

[johnstcn]

We are currently on a fork of github.com/GoogleContainerTools/kaniko (github.com/coder/kaniko).

Our fork includes some extra changes that are not included in upstream Kaniko:

• Add options for capturing run output to GetCommand (https://github.com/coder/kaniko/commit/30ddbe50d716d5c86ad7a558ecc4fbee2c0d76f7)

• ~Set default UserID and GroupID to 0:0 (https://github.com/coder/kaniko/commit/6431577896f1b557401c9a1fb1926398bad238b7) (related to https://github.com/GoogleContainerTools/kaniko/issues/1921)~

[mafredri]

@johnstcn with 43b5b373864247394c3204ac34342ee802d1ce9a, is the only remaining issue the output capture?

Would it be feasible to run Kaniko as an external program and capture the output that way? Or are we tweaking the behavior in a way that can't be adjusted via env/flags?

I think it's still valuable if we can embed Kaniko, but that's quite easily achieved via:

import (
    "os"

    "github.com/GoogleContainerTools/kaniko/cmd/executor/cmd"
)

func main() {
    if err := cmd.RootCmd.Execute(); err != nil {
        os.Exit(1)
    }
}

The benefit of this would be that we can support both modes of operation, external or embedded Kaniko.

[johnstcn]

I believe that's the only reason. I think the change you propose is possible as a refactor.

[mafredri]

Alright, thanks for confirming. OTOH, with #124 we'll be still need to maintain a fork. 😅

[johnstcn]

We'll need to stay on our own fork for the foreseeable future.