github.com/GoogleContainerTools/skaffold/v2@v2.13.2/docs-v2/design_proposals/transparent-init.md (about)

     1  # Transparent Init
     2  
     3  * Author(s): Marlon Gamez
     4  * Design Shepherd: \<skaffold-core-team-member\>
     5  * Date: 10/13/2020
     6  * Status: [Reviewed/Cancelled/Under implementation/Complete]
     7  
     8  ## Background
     9  
    10  This proposal is brought about by an older issue, [#1273](https://github.com/GoogleContainerTools/skaffold/issues/1273)
    11  
    12  With the recent focus on skaffold UX, we've decided to see how we can improve the onboarding experience when using skaffold.
    13  One way we'd like to do this is by allowing the user to simply install skaffold and run skaffold commands like `run`, `dev`, or `debug` in their project, without having to first run `skaffold init` and go through the interactive portion of creating a config for their project.
    14  To do this, we'd like to automatically create a config upon invocation of skaffold commands, so that the user doesn't have to see something like this
    15  ```
    16  ❯ skaffold dev
    17  skaffold config file skaffold.yaml not found - check your current working directory, or try running `skaffold init`
    18  ```
    19  when trying to run skaffold.
    20  
    21  ## Scope
    22  
    23  This proposal is meant to design the flow of a user running a command without a skaffold config file already on disk. It does not cover the actual functionality of `skaffold init --force`, and doesn't address the further changes that will be made to that functionality.
    24  
    25  This functionality is planned to initially work with the `run`, `dev`, and `debug` commands, as we want to cater to the commands that are meant to provide the best first time UX.
    26  
    27  ## Design
    28  
    29  With transparent init, a user's first run of `skaffold dev` could look something like this:
    30  
    31  Given a simple project structure:
    32  ```
    33  project-dir
    34  ├── Dockerfile
    35  ├── README.md
    36  ├── k8s-pod.yaml
    37  └── main.go
    38  ```
    39  Running skaffold dev:
    40  ```
    41  ❯ skaffold dev
    42  This seems to be your first time running skaffold in this project. If you choose to continue, skaffold will:
    43  - Create a skaffold config file for you
    44  - Build your application using docker
    45  - Deploy your application to your current kubernetes context using kubectl
    46  
    47  Please double check the above steps. Deploying to production kubernetes clusters can be destructive.
    48  
    49  Would you like to continue?
    50  > yes
    51    no
    52  
    53  Listing files to watch...
    54   - skaffold-example
    55  Generating tags...
    56   - skaffold-example -> skaffold-example:v1.14.0-59-g7e5ae4cbc-dirty
    57  Checking cache...
    58   - skaffold-example: Not found. Building
    59  Found [minikube] context, using local docker daemon.
    60  Building [skaffold-example]...
    61  Sending build context to Docker daemon  3.072kB
    62  ...
    63  ```
    64  
    65  There are two approaches to implementation that I've considered:
    66  
    67  **Creating the config in memory using init functions (Preferred)**
    68  
    69  Under the hood view:
    70  - `skaffold dev` is run
    71  - skaffold searches for a `skaffold.yaml` file in the directory, finds nothing
    72  - `skaffold init` is run to generate a config
    73  - user is prompted as shown above
    74  - if user selects "yes", `skaffold dev` continues like normal
    75  
    76  **Creating a temporary `skaffold.yaml` by running `skaffold init --force`**
    77  
    78  Under the hood view:
    79  - `skaffold dev` is run
    80  - skaffold searches for a `skaffold.yaml` file in the directory, finds nothing
    81  - skaffold creates a new config using `skaffold init --force`
    82  - the new config is parsed and brought into memory
    83  - the config file is deleted from disk
    84  - `skaffold dev` continues like normal
    85  
    86  ## Open Issues/Questions
    87  
    88  **Should generation of the config all happen in memory? By refactoring `DoInit()` we could probably generate the config and start using it without having to write/read the `skaffold.yaml` from disk**
    89  
    90  I think this would be preferred. We could eliminate an unecessary read from disk by doing so.
    91  
    92  **Should we prompt the user to ask if they'd like to save this config for future use?**
    93  
    94  I believe that it would be fine to write to disk automatically. The logging will make it clear that this is being done and after the skaffold session is finished they can decide to remove the file or not. 
    95  
    96  **Should the config being used be printed to the terminal? Tradeoff of information vs clutter**
    97  
    98  I would say that we don't need to. Printing the config would add a large clutter, and if the user needs to view the config used, they can view the skaffold config that is written to disk.
    99  
   100  ## Implementation plan
   101  
   102  If we decide to have the config written to disk and kept in memory, we may want to split this into a couple PRs. Maybe something like this:
   103  1. Refactor `DoInit()` so that it is broken into parts that we can use later
   104  2. Use the new parts to implement the automatic generation of the config
   105  
   106  If we decide upon the approach in which the `skaffold.yaml` is written to/read from disk, this could be done in 1 PR, as a refactor wouldn't be necessary.
   107  
   108  ## Integration test plan
   109  
   110  New integration tests can be added to check that invocations of skaffold commands in folders without a skaffold config still run properly. With the other plans to change skaffold init, these will have to be updated as well.