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

FR: Provide override flag for terminal check #132

Open
jhillyerd opened this issue Jun 1, 2022 · 5 comments
Open

FR: Provide override flag for terminal check #132

jhillyerd opened this issue Jun 1, 2022 · 5 comments
Labels
enhancement New feature or request

Comments

@jhillyerd
Copy link

My cook stage in failing inside a Kaniko automated builder running inside a docker container, it seems to have fooled atty::is(atty::Stream::Stdout)

It would be helpful to have a flag to force it to continue.

Output:

INFO[0102] Taking snapshot of full filesystem...        
INFO[0108] cmd: /bin/sh                                 
INFO[0108] args: [-c cargo chef cook --recipe-path recipe.json] 
INFO[0108] Running: [/bin/sh -c cargo chef cook --recipe-path recipe.json] 
WARNING stdout appears to be a terminal.
cargo-chef is not meant to be run in an interactive environment and will overwrite some existing files (namely any `lib.rs`, `main.rs` and `Cargo.toml` it finds).

To continue anyway, type `yes`: error building image: error building stage: failed to execute command: waiting for process to exit: exit status 1
exit status 1

If you have a preferred name for the flag, I can make a PR.

@jhillyerd
Copy link
Author

It seems tee can be used as a workaround for now:

cargo chef cook --recipe-path recipe.json | tee /tmp/cook.txt

@LukeMathWalker
Copy link
Owner

This feels like an issue upstream - either in atty (false negative) or kaniko.

@jhillyerd
Copy link
Author

I think that assuming the presence of a TTY means it is always an interactive session is a mistake, the build shouldn't break because of it.

@LukeMathWalker
Copy link
Owner

It's true that it can break down in some edge cases, but I do wonder if this is intentional for kaniko.

@jhillyerd
Copy link
Author

In my case, I'm using (testing really) Hashicorp Waypoint, which starts up a build runner as a docker container within a Nomad cluster. That runner apparently uses kaniko to build the docker image, but I don't have direct control over the kaniko config, or a way to introspect it.

I do see this random blog post intentionally enabling tty for kaniko+Jenkins, but I don't know why, perhaps related to the debug executor: https://support.cloudbees.com/hc/en-us/articles/360031223512-What-you-need-to-know-when-using-Kaniko-from-Kubernetes-Jenkins-Agents

I don't think I will be continuing with this kaniko-on-a-cluster build system, as it doesn't actually benefit from any of the layer caching that chef gives me when building locally, so the builds are incredibly slow. It was an experiment.

@LukeMathWalker LukeMathWalker added the enhancement New feature or request label Jul 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants