googlecontainertools / skaffold Goto Github PK

I started to go down the route of figuring out how to work with Skaffold and use a remote debugger (delve in my case).

The only thing I really needed from Skaffold was for it to be able to reconfigure a port-forwarding setup to one of the new pods that was created.

I think it could look something like:

portForwarding:
  - labelSelector:
      app: my-app
      component: backend
    port: 2345
  - labelSelector:
      app: my-app
      component: frontend
    port: 8080:80

Skaffold could pick the most recently deployed pod that matches the selectors, although some more precise detection of the "right pod" may be necessary.

https://github.com/GoogleCloudPlatform/skaffold/blob/master/pkg/skaffold/deploy/kubectl.go#L67

It should definitely be expanded to cover .yaml, .yml, and .json.

Additionally, if the file is a specific reference to a file and not a glob, we should try to deploy that regardless.

When a ConfigMap manifest is updated, users may want that to automatically update the workload that it references. Unfortunately the deployment will only update if the configmap name or any other field changes in the spec.

Do we want to expand bash substitutions in some skaffold fields? It is a bit of feature creep, but might be useful for complete portability of skaffold.yaml

We could ship examples for other repos by including a workspace: $GOPATH/src/path/to/project, so that we don't need to keep all of the example code here, only the example configuration.

It also makes paths less fragile, since its not so dependent on where the user actually runs skaffold run.

Here's a library we could use (note: haven't used it before, this is just the result of a quick google search)
https://github.com/drone/envsubst

This is an umbrella issue for some ideas on how we might clean up the development artifacts we create in a skaffold dev pipeline.

• Auto prune images/tags to save disk splace

Port this code and add tests https://github.com/r2d4/skaffold/blob/master/pkg/skaffold/kubernetes/logs/logs.go

And authentication to private repositories

Add prechecks to both builders and deployers to ensure basic conditions before the pipeline is ran. This could be implemented as an interface that both Builder and Deployer embed.

Some ideas for prechecks:

• LocalBuilder: Ensure connection to docker daemon
• KubectlDeploy: Ensure connection to cluster, kubectl installed
• HelmDeploy: Ensure connection to cluster, helm installed, (tiller installed?)

Should these prechecks also verify manifest conditions? I think eventually we might want to add some sort of linting of kubernetes resources, and possibly extend that to skaffold resources.

We should have something like this

	return apimachineryversion.Info{
		Major:        gitMajor,
		Minor:        gitMinor,
		GitVersion:   gitVersion,
		GitCommit:    gitCommit,
		GitTreeState: gitTreeState,
		BuildDate:    buildDate,
		GoVersion:    runtime.Version(),
		Compiler:     runtime.Compiler,
		Platform:     fmt.Sprintf("%s/%s", runtime.GOOS, runtime.GOARCH),
	}

https://github.com/kubernetes/kubernetes/blob/master/pkg/version/version.go#L31-L40

Formattable with the TemplateFlag in skaffold version

We should add info and debug level logging to this function also. As we add more build and deploy implementations, we'll be using this a lot so it should have good test coverage.

To test exec.Command, we can shell out to the test binary like the std library does https://github.com/golang/go/blob/master/src/os/exec/exec_test.go#L33

We can also use the fake readclosers in our testutil package.

I don't think theres much harm into trying an initial build, since we should just warn if its fails anyways.

https://github.com/GoogleCloudPlatform/skaffold/blob/910aa891c5f2dc28cdc95602067f0a1ca45f5806/pkg/skaffold/build/local.go#L60-L62

https://github.com/GoogleCloudPlatform/skaffold/blob/87beed031679b0e350ef6e3c07c3fa57001f43cb/pkg/skaffold/watch/watch.go#L107-L109

We should mimic the resolution that the docker cli does here. We support a very basic version here, but it should be its own function to infer workspace and dockerfile paths.

Dockerfile="" ====> Dockerfile="Dockerfile"
Workspace="" ====> Workspace="."

Dockerfile="" ====> Dockerfile="Dockerfile"
Workspace="dir/Dockerfile" ====> Workspace="dir"

All examples should be covered by integration tests. We should always keep examples up to date with new changes, and convey to the users clearly when there are breaking change. We can do this with release notes or config comments.

This is already provided by the CLI library we're using.

When deploying, you may want to define a specific cluster to use rather than the one that is configured on the local host.

We are not processing the messages from the docker daemon or registry properly, so output isn't as pretty as it should be. We should compress status updates for the same layers, add progress bars, etc.

Example:

abe52c89597f: Verifying Checksum
abe52c89597f: Download complete
96e333289084: Verifying Checksum
96e333289084: Download complete
39cd5f38ffb8: Verifying Checksum
39cd5f38ffb8: Download complete
503166935590: Verifying Checksum
503166935590: Download complete
ce145c5cf4da: Verifying Checksum
ce145c5cf4da: Download complete
503166935590: Pull complete
abe52c89597f: Pull complete
ce145c5cf4da: Pull complete
96e333289084: Pull complete
39cd5f38ffb8: Pull complete

In other projects I've worked on, there has been a command (something like skaffold debug) that puts together either a bundle of artifacts or prints out information that can be useful for maintainers to either reproduce or further debug issues that are reported. We could add a note to the issue template that asks users to run this command and add the info to their report.

Even though we can calculate all the dependencies, users might not want to (or be able to) watch all dependencies for a large project. We should figure out how we want to expose a ignore functionality to the user

#15 (comment)

These are currently not watched. The dockerfile is easy to watch, however we need a way for deploy implementations to expose their dependencies.

We need to make sure that some parameters are valid docker tags before it gets to the downstream tools and fails. We should vendor in the validation from docker/moby

Add ability to deploy to a specific cluster context or maybe multiple contexts.

Exposing the build and deploy steps as single runnable commands

$ skaffold build local
$ skaffold deploy helm --chart-path

We could autogenerate most, if not all, of the command by iterating over BuildType and DeployType and then generating flags based on the parameters on the subtypes like LocalBuild. Each command would output a go-template BuildResult or DeployResult.

Currently you have to have

local
  push: true

This is part of #47

DOCKER_HOST
DOCKER_CERT_PATH
etc.

We read these from the environment variables now (or generate them from minikube), but it might be useful to expose these options as overrides in the config.

A few possible ideas:

1. Have a new "project" for every release

• Might make more sense once we've gotten some users

2. Have a new "project" for alpha, beta, GA

• At the early stages (pre-release), tracking alpha and beta features might be more valuable than releases

3. Don't use it at all

• GitHub projects just recently added support for automatically moving "cards" from different stages based on status. In short, there are a lot of features missing and its historically been hard to use.

4. One large meta project that has subtabs broken down by releases or milestones

I've started a basic version of 2. I don't have strong opinions here and would love to hear your thoughts or what you've seen work well @viglesiasce @dlorenc

I'd like to manually release an alpha binary pending

• #90
• #81
• #85
• #29
• #30

ref #79

Currently, all artifacts are rebuilt after one source file changes, and changes during the build and deploy pipeline are ignored.

Port this code and add tests

https://github.com/r2d4/skaffold/blob/master/pkg/skaffold/builder/minikube.go

brew install skaffold

Instead of having to list every manifest

We don't currently support the scenario when an ENV is inherited from the parent image and then used in the source of a COPY or ADD. As a short term solution, we can add the entire context, but we might want to figure out a way to resolve those ENVs without adding everything.

We'll have to download and inspect parent dockerfiles for deferred instructions.

Opening an issue to get some discussion started on how skaffold can keep track of what it's deploying through the various deployers we support (helm, kubectl apply, ksonnet, etc.).

Tracking these artifacts can help with things like #94 and deletion cases.

For kubectl, we know the manifest paths so we could parse those YAMLs and apply labels, or build a label selector?

For helm, we know the release names so we can query them with helm list or something similar.