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

Setting to control "transparent init" behavior #8664

Open
blightbow opened this issue Apr 11, 2023 · 0 comments
Open

Setting to control "transparent init" behavior #8664

blightbow opened this issue Apr 11, 2023 · 0 comments
Labels
area/init kind/friction Issues causing user pain that do not have a workaround priority/p2 May take a couple of releases

Comments

@blightbow
Copy link

blightbow commented Apr 11, 2023

Executing various skaffold subcommands (skaffold run, etc.) in the wrong directory will invoke the "transparent init" behavior. (proposed in #1273, implemented in #5186) This feature can be useful when invoked within a project directory, but also extremely undesirable when not. For example, if a user with a large home directory structure accidentally pastes skaffold run into their terminal from the base of their home directory (wrong terminal, mistaken working directory, etc.), this will trigger an init scan of their home directory that is unexpected and in some cases time consuming. This init can sometimes be difficult to break out of with ctrl-c.

It is a given that software need not adhere to the principle of least astonishment to the point of inconvenience, but ignoring it should not result in inconvenience or potentially disruptive behaviors by default.

Expected behavior

skaffold init should not be an unrequested behavior. Some suggestions:

  • Add an option that can be placed in the global config that enables transparent init without prompting. (the current behavior) I'm going to refer to this option as transparent-init for now, since it is consistent with the name used internally to refer to this feature.
  • Consider multiple values for the transparent-init setting:
    • yes: The current default. Immediately invoke skaffold init with no prompting. It should be the default when a terminal is not present, but non-interactive tools should be able to request no via the commandline option if it is undesirable. This would maintain backward compatibility with unattended execution that relies on the current default, such as with scripts or VS Code plugins.
    • no: Fail normally with no prompting. This was the behavior prior to Add transparent init #5186 if I'm not mistaken.
    • ask: A new mode that I am proposing below. It should be the default when a terminal is present.
  • ask mode would be new and is intended to be a compromise between the two previous behaviors.
    • It should only be available when a terminal is detected. If a terminal is not connected, ask should be treated as yes.
    • The user is prompted for whether they wish to run skaffold init, and a message should be printed that drives the user's attention to the existence of the new transparent-init option that makes this prompt go away. (by setting the mode to yes or no)

There is a lot of impact to consider with this change, and the above proposal is intended to be flexible while minimizing the impact to external dependencies. Please offer feedback and alternatives.

Information

  • Skaffold version: v2.3.0
  • Operating system: Ubuntu 20.04.4
  • Installed via: skaffold.dev
  • Contents of skaffold.yaml: N/A

Steps to reproduce the behavior

  1. Change working directory to any path on a filesystem that incorporates many nested subdirectories with a large file count.
  2. Execute any subcommand of skaffold that redirects the user into skaffold init if a configuration file is not found, such as skaffold run.
  3. Suffer, if you're unlucky. :)
@aaron-prindle aaron-prindle added area/init kind/friction Issues causing user pain that do not have a workaround priority/p2 May take a couple of releases labels Apr 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/init kind/friction Issues causing user pain that do not have a workaround priority/p2 May take a couple of releases
Projects
None yet
Development

No branches or pull requests

2 participants