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.

Sign up for GitHub

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

Clarify how Skaffold resolves files #5467

Merged
merged 2 commits into from
Mar 17, 2021
Merged

Clarify how Skaffold resolves files #5467

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
89aa29f
Clarify how Skaffold resolves files
briandealwis Feb 26, 2021
04b2aca
Add clarifications
briandealwis Mar 17, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 39 additions & 6 deletions docs/content/en/docs/design/config.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,11 +6,7 @@ aliases: [/docs/concepts/config]
---

You can configure Skaffold with the Skaffold configuration file,
`skaffold.yaml`. The configuration file should be placed in the root of your
project directory; when you run the `skaffold` command, Skaffold will try to
read the configuration file from the current directory.

`skaffold.yaml` consists of several different components:
`skaffold.yaml`. The configuration file consists of several different components:

| Component | Description |
| ---------- | ------------|
Expand All @@ -25,6 +21,43 @@ read the configuration file from the current directory.

You can [learn more]({{< relref "/docs/references/yaml" >}}) about the syntax of `skaffold.yaml`.

Skaffold normally expects to find the configuration file as
`skaffold.yaml` in the current directory, but the location can be
overridden with the `--filename` flag.

### File resolution
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add a File resolution section down below or mention here itself about configurations resolved as dependencies. The paths in those files are resolved relative to the directory containing the imported file. So it's recommended to have the skaffold.yaml file live in the root of the project and not in a nested directory.


The Skaffold configuration file often references other files and
directories. These files and directories are usually referenced
relative to the current directory _and not to the location of
the Skaffold configuration file_. There is one important exception:
files referenced from a build artifact definition are resolved
relative to the build artifact's _context_ directory.

In the following config file, the `Dockerfile` for building `app`
is resolved relative to the `frontend` directory (i.e., `frontend/Dockerfile`),
whereas the the Helm chart's location and its values-files are
relative to the current directory in `helm/project`.
```yaml
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also show the directory tree?

.
├── frontend
│   └── Dockerfile
├── helm
│   └── project
│       └── dev-values.yaml
└── skaffold.yaml

apiVersion: skaffold/v2beta11
kind: Config
build:
artifacts:
- image: app
context: frontend
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we mention that if context is not explicitly defined then it's set to the CWD anyway?

docker:
dockerfile: "Dockerfile"
deploy:
helm:
releases:
- name: project
chartPath: helm/project
valuesFiles:
- "helm/project/dev-values.yaml"
artifactOverrides:
image: app
```

## Configuration dependencies

In addition to authoring pipelines in a skaffold configuration file, we can also import pipelines from other existing configurations as dependencies. Skaffold manages all imported and defined pipelines in the same session. It also ensures all artifacts in a required configs are built prior to those in current config (provided the artifacts have dependencies defined); and all deploys in required configs are applied prior to those in current config.
Expand Down Expand Up @@ -107,4 +140,4 @@ requires:
activatedBy: [profile2, profile3]
```

Here, `profile1` is a profile that needs to exist in both configs `cfg1` and `cfg2`; while `profile2` and `profile3` are profiles defined in the current config `cfg`. If the current config is activated with either `profile2` or `profile3` then the required configs `cfg1` and `cfg2` are imported with `profile1` applied. If the `activatedBy` clause is omitted then that `profile1` always gets applied for the imported configs.
Here, `profile1` is a profile that needs to exist in both configs `cfg1` and `cfg2`; while `profile2` and `profile3` are profiles defined in the current config `cfg`. If the current config is activated with either `profile2` or `profile3` then the required configs `cfg1` and `cfg2` are imported with `profile1` applied. If the `activatedBy` clause is omitted then that `profile1` always gets applied for the imported configs.