Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Document steps to use sErrors.ErrDef class to provide actionable error messages #5375
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
Document steps to use sErrors.ErrDef class to provide actionable error messages #5375
Changes from all commits
90e099a
03114a1
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Development
This doc explains the development workflow so you can get started contributing to Skaffold!
Requirements
You must install these tools:
go
: The language skaffold is built in (version >= go 1.14)git
: For source controlmake
: For building skaffold.Getting started
First you will need to setup your GitHub account and create a fork:
Once you have those, you can iterate on skaffold:
When you're ready, you can create a PR!
You may also be interested in contributing to the docs.
Checkout your fork
To make local changes to skaffold and eventually submit a pull request to the repo, we recommend creating your own fork.
Once you've done this, clone your fork to your local machine:
Adding the
upstream
remote sets you up nicely for regularly syncing your fork.IDE setup
Skaffold uses go modules and we commit to the
vendor
directory all our dependencies to make CI faster.We recommend checking out Skaffold outside of the
GOPATH
.JetBrains Goland:
File > Open...
(choose your skaffold directory)Go > Go modules > Vendoring mode
is checkedJetBrains IntelliJ with Go plugin:
File > Open...
(choose your skaffold directory)Visual Studio Code with Go plugin:
File > Open...
Making a config change
Some changes to the skaffold code require a change to the skaffold config. These changes require a few extra steps:
Open the latest Config at pkg/skaffold/schema/latest/config.go and inspect the comment at L25
If the line mentions the config version is not released, proceed making your changes.
If the line mentions the config version is released then,
Run
./hack/new_version.sh
to create a new version.Run
make test
to verify changes.Commit these generated changes, and submit a PR.
Once you've done this, merge or rebase your development branch with config changes, including the new config change. Any new config changes belong in pkg/skaffold/schema/latest/config.go. Do not edit the older config versions.
Be sure and update the documentation in
pkg/skaffold/schema/<previous_config_version>/upgrade.go
with any additions, removals, or updates you make to the config.In case of backwards compatibility issues, update the
Upgrade()
method from the previous config version appropriately. This is usually required when a previously existing field in the config is changed, but not when a new field is added.Note: the Upgrade() method is called by skaffold automatically for older config versions. This can also be done manually by users by running
skaffold fix
.make test
locally. This will regenerate the JSON schemas for the skaffold config with your new changes. Commit the resulting changes autogenerated by the scripts.For more details behind the logic of config changes see the Skaffold config management doc.
Making changes to the Skaffold API
We build the API directly through gRPC, which gets translated into REST API through a reverse proxy gateway library. If you make changes to the proto/skaffold.proto file you can run
./hack/generate-proto.sh
to generate the equivalent Go code.Adding actionable error messages to code.
Skaffold has a built-in framework to provide actionable error messages for user to help bootstrap skaffold errors.
Also, v1.19.0 onwards, skaffold is collecting failure error codes to help the team get more insights into common failure scenarios.
To take advantage of this framework, contributors can simply use the
ErrDef
struct to throw meaningful actionable error messages and improve user experience.e.g In this example PR,
INIT
in this case stands for skaffoldINIT
phase which includes, parsing of skaffold config and creating a skaffold runner. The other valid phases areBUILD
,DEPLOY
,STATUSCHECK
. Complete list herehack/generate_proto.sh
. These will generate go code and structs for the newly added proto fields.sErrors.NewError
in pkg/skaffold/errors to inantiate an object of structErrDef
.ErrDef
implements the golangerror
interface.With above two changes, skaffold will now show a meaning full error message when this error condition is met.
Building skaffold
To build with your local changes you have two options:
Build the skaffold binary:
You can then run this binary directly, or copy/symlink it into your path.
Build and install the skaffold binary:
This will install skaffold via
go install
(note that if you have manually downloaded and installed skaffold to/usr/local/bin
, this will probably take precedence in your path over your$GOPATH/bin
).If you are unsure if you are running a released or locally built version of skaffold, you can run
skaffold version
- output which includesdirty
indicates you have built the binary locally.Verifying local changes
If you are iterating on skaffold and want to see your changes in action, you can:
Testing skaffold
skaffold has both unit tests and integration tests.
Unit Tests
The unit tests live with the code they test and can be run with:
make test
In case you see a linter error such as:
re-run the
hack/install_golint.sh
script to upgradegolangci-lint
.Integration tests
The integration tests live in
integration
. They can be run with:These tests require a Docker daemon, a Kubernetes cluster and all the tools used by every Builder and Deployer, such as kubectl, bazel, java, kustomize...
A way to run the integration tests without installing those tools and without depending on a Kubernetes cluster is to install kind and run:
Running a subset of integration tests
You can select specific integration tests to run via the
INTEGRATION_TEST_ARGS
env var:INTEGRATION_TEST_ARGS="-run=TestDev/" make integration
Running GCP specific integration tests
Another set of the integration tests require a GCP project because they will push to a GCR registry or use Cloud Build to build artifacts. Those tests can be run with:
These tests will be kicked off by reviewers for submitted PRs.
Building skaffold docs
The latest version of the skaffold site is based on the Hugo theme of the github.com/google/docsy template.
Testing docs locally
Before creating a PR with doc changes, we recommend that you locally verify the generated docs with:
Once PRs with doc changes are merged, they will get automatically published to the docs for the latest build to https://skaffold-latest.firebaseapp.com. which at release time will be published with the latest release to https://skaffold.dev.
Previewing the docs on the PR
Mark your PR with
docs-modifications
label. Our PR review process will answer in comments in ~5 minutes with the URL of your preview and will remove the label.Testing the Skaffold binary release process
Skaffold release process works with Google Cloud Build within our own project
k8s-skaffold
and the skaffold release bucket,gs://skaffold
.In order to be able to iterate/fix the release process you can pass in your own project and bucket as parameters to the build.
We continuously release builds under
gs://skaffold/builds
. This is done by triggeringcloudbuild.yaml
on every push to master.To run a build on your own project:
We release stable versions under
gs://skaffold/releases
. This is done by triggeringcloudbuild-release.yaml
on every new tag in our Github repo.To test a release on your own project:
To just run a release without Google Cloud Build only using your local Docker daemon, you can run:
Creating a PR
When you have changes you would like to propose to skaffold, you will need to:
Please follow our small Pull Requests guidelines for quicker response time.
Reviews
Each PR must be reviewed by a maintainer. This maintainer will add the
kokoro:run
label to a PR to kick off the integration tests, which must pass for the PR to be submitted.