We need simple parameters.

Enable auto-reloading of containers when a set of files change.

Follow-up to argoproj/argo-workflows#11928 (comment) and argoproj/argo-workflows#11423.

[...] Codespaces running indefinitely on kit pre-up: argoproj/argo-workflows#11423. I even got a notification from GH that it used up 24 hours of compute before I even had access to a terminal (it apparently ran all night even after I closed the tab and turned off my computer).
I just looked into that yesterday and think it can be solved by switching the devcontainer's onCreateCommand to a postCreateCommand, but something weird is going on with how Codespaces is interacting with kit specifically at build-time. I saw it restart a few processes repeatedly too, not sure why.

Possibly related to #42 given the restarts I saw, but not sure

I’d like the option to disable watching for file changes. The use case is, I don’t want to restart services because I’m using hot reload which is much faster.

Lint configuration.

Currently, when a task goes into error state it is hard to know what went wrong. It is not enough to look at the just the stderr, you will also need to look at stdout.

Also, when readiness is failing.

Skaffold handles the workflow for building, pushing and deploying your application, allowing you to focus on what matters most: writing code.

13k stars.

Are your servers running locally? In Kubernetes? Both? Tilt gives you smart rebuilds and live updates everywhere so that you can make progress.

6.2k stars.

Telepresence gives developers infinite scale development environments for Kubernetes.

5.5k stars.

DevSpace is an open-source developer tool for Kubernetes that lets you develop and deploy cloud-native software faster.

3.3k stars

Garden combines rapid development, testing, and DevOps automation in one tool. Get realistic cloud-native environments for every occasion and never worry about the difference between dev, CI and prod again.

2.7k stars.

Draft is a tool made for users who are just getting started with Kubernetes, or users who want to simplify their experience with Kubernetes.

250 stars

Dev Environments lets you create a configurable developer environment with all the code and tools you need to quickly get up and running.

E.g.

kit -f other.yaml up

How does this work with dev containers?

It might be useful to only run tasks under certain conditions. Eg only run a build if a file does not exist.

Today you must specify the task you want to run.

What about if it just ran everything instead? How would you choose to just run some tasks?

When kit.yaml changes, we should reload.

Currently, Kit re-writes the tasks.yaml, loosing comments. I don't like that.

If you want to change many environment variables at once you need to give them all. It is verbose. It might be nice to have .env files imported, e.g. “kit -e test” would import “test.env”.

I would be good to be able to conditionally run tasks. This would be a bit like Github actions, e.g.`

- name: foo
   command: sh script
   if: success()

- name: foo
   command: sh script
   if: failure()

- name: foo
   command: sh script
   if: always()

- name: foo
   command: sh script
   if: env.FOO == 1

• Reference
• Schema
• Examples
• #23

When running with Docker Desktop that is logged in, it failed with the following error:

failed to pull image: Error response from daemon: Please run 'docker login'

Running docker login does not fix this.

All I know is that when I swapped it out, my fans made a lot less noise and my memory usage was considerably lower 😅 .
I did not trace it carefully, but it seemed like there might be a memory leak in the auto-restart feature or something as I noticed the memory just kept increasing when I made changes to the code and not going back down. It could be a memory leak in one of the tasks themselves too though; again, I did not trace it, that was merely an observation and not one of the initial motivators.

There aren't too many places there could be a memory leak. Perhaps it is in the watch?

Apps tend to consist of:

• Downstream dependencies. E.g. Kafka. These don’t generally go faulty, because faults are caused by code changes.
• The app itself. This goes faulty a lot, because user changes the code and introduces faults.

When app goes faulty, we want to see the logs:

1. All logs, muxed to the terminal.
2. Just the app logs.

Currently we do (2). Should we do (1)?

What I actually do is have a second terminal open running tail -f. This is poor UX.

Should we switch out of max mode automatically?

If I set:

- name: controller
  env:
    - ARGO_LOG_LEVEL=debug

in argo-workflows' tasks.yaml file, it seems to have no effect. (I haven't tried the other environment variables.)

Having each service/task/background process have a custom color and prefix would be nice.

prefixes

Generally I'm fine with the default prefix of using the task name, but I think it's more commonly [task] rather than task: (the latter is what Kit currently does). Brackets are more obvious to me that it's a prefix as well, since they are not used in logs commonly (whereas colons sometimes are).

colors

Having each task log as a different color from each other is super useful for readability, IMO. A different color with good contrast by default would be great. (WCAG compliant colors are ideal, although this is a terminal, not a web interface, so WCAG does not quite apply, but the contrast semantics are still useful for accessibility).

task comparison for reference

Task lets you choose an "output mode" (group/interleaved/prefixed) and lets you customize the prefix per task. Colors can be globally configured and toggled with env vars, but doesn't seem like they can be customized per task.

I’d like to be able to label a task with one of more profiles and the run ‘kit -p profile-1 up’ so it only runs those tasks.

Support up from a repo.

Mentioned in #40 (comment) but didn't get an answer. I think this behavior is not currently supported.

Task supports specifying sources and generates and will perform a checksum or timestamp (checksum is the default, timestamp matches Make) check on those when specified. If the files listed in generates exist and the sources haven't changed, the task will not be run.

Make supports a similar feature by default that uses timestamps.

Would be good feature parity for Kit to support this, especially as it can result in using a lot less compute and time

Wants

• Easy to type: 2 or 3 letters long, that flow.
• Unique.
• Work well with up and down sub-commands. E.g. spin up

Ideas

• awn
• spin
• app
• pup
• pu
• joy

This is a suggestion for a demo that the docs can go over. Would consider this part of docs but some kind of demo that shows the marriage of docker tasks and non docker tasks. Perhaps something resembles a pseudo twitter app:

couple of docker containers:

• postgres
• memcache

simple app in something like node or java that provides a simple account / tweet type data model backed by posgres and leverages memcache as a cache layer.

With something like this you can show:

• standard docker containers
• an app under development leveraging those containers
• some kind of liveness probe of the code under test

Summary

I'm not really sure why this is happening, but when Node deps change, sometimes a task that does yarn install will just run indefinitely and never finish inside of Kit.

Details

The ui-deps task in Argo Workflows runs yarn install and several times I have noticed it just run for many minutes, at which point I just Ctrl+C to kill it.
Then I run yarn install manually outside of Kit, and it installs everything fine within 30s. When I run Kit again after the manual yarn install, Kit will run fine.

yarn install always runs something, but it basically no-ops when there's nothing to install.

Hypothesis

I have a feeling this may be because of the auto-updating progress indicator that Yarn has. Kit seems to not capture it properly in its logs, and so maybe it's failing to see it finish? I think this requires a TTY or something (I forget the exact terminology and shell semantics here, but similar to docker -t. See also this SO Answer on shell output buffering)

Example

For example, in the below Kit run:

■ go-deps    waiting  waiting for mutex "downloads"
■ install    waiting  
■ build-cont waiting  
■ port-forwa waiting  [9000] 
■ controller waiting  [9090] 
■ build-argo waiting  
■ server     waiting  [2746] 
■ ui-deps    running  warning " > [email protected]" has incorrect peer dependency "react-dom@>=17.0.0".
■ ui         waiting  [8080] 

ui-deps will have the same message indefinitely. Enabling debug logging with "4+Enter" shows no logs either.
That message is the last message before Yarn's installation progress indicator, which is a self-updating message (i.e. it does not output new lines, it continuously updates the same log line) of the form: ####------ 4/10 (but longer), where the percentage of hashes and the number represents progress.

For example, task and xc are existing, quite popular task runners written in Go that largely cover the same feature set.

And other tools that have slightly different goals, such as just, mask, and Earthly (Earthly is my current go-to for a variety of reasons).

Automatically reformat the YAML.