`commonLabels` is deprecated, but the field did not have a deprecation comment,
like other fields do. Add the deprecation comment, as some IDEs use that as a
guideline to show a strikethrough in the field names (and to follow the pattern
of other deprecated fields).
Include configuration for the new `ValidatingAdmissionPolicy` and
`ValidationAdmissionPolicyBinding` APIs so that Kustomize can natively configure
the `policyName` field in `ValidatingAdmissionPolicyBinding` with the transformed
name of `ValidatingAdmissionPolicy`.
- Pin to v5.4.1 with sha256 as example of how to ensure supply-chain
security. Pulling the latest kustomize image or source is insecure
without checksum validation.
- Bump example image tag to v0.1.1
* fix: use fmt.Errorf ubstead if non-exising `errors.New`
When https://github.com/kubernetes-sigs/kustomize/pull/5525 merged, it
referenced `errors.New` function but that function doesn't exist.
This PR replaces the call with simple `fmt.Errorf`.
* Add lint check with kustomize_disable_go_plugin_support
* move lint-api-static to /api/Makefile
* clean golangci cache
* feat: support labels key in transformer configuration
Allow the usage of a separate transformer configuration for the labels key,
similar to what is currently available for commonLabels and commonAnnotations.
This aims to provide the same functionality that commonLabels currently provide
for labels, since commonLabels is deprecated and slated for removal in a future
release.
* chore(transformerconfig): add nolint hint
Add a nolint hint to the new method so the returns can stay consistent with
one another.
* fix: changes from code review
* Rename methods `AddCommonLabelFieldSpec` and `AddLabelFieldSpec` to
`AddCommonLabelsFieldSpec` and `AddLabelsFieldSpec`.
* Add extra test to verify scenarios applying labels to Custom Resource Definitions.
* Pin tool versions with hack/go.mod
This change centralizes the tracking of versions for tools used for
development and testing. This way, the tools and all their
dependencies have their checksums stored in hack/go.sum, which
improves supply chain security.
* Workspace Sync & Tidy
* Add buildMetadata task and ref
Move build metadata tasks, draft buildMetadata reference
Clean up buildMetadata ref
Add managed by label task
Add local non-generated task
Add local generated resource
Add remote generator task
Clean up tasks and ref
Add local transformer annotation example
Add local and remote transformer example
* Address PR feedback and general cleanup
cherrypick updates from feature branch
fix script
fix release script
Assert keeps going after failure, but require immediately fails
the tests, making it easier to find the output related to the test
failure, rather than having to comb through a bunch of subsequent
assertion failures. For equality tests, we may or may not want to
continue, but for error checks we almost always want to immediately
fail the test. Exceptions can be changed as-needed.
- go mod tidy (all modules)
- go work sync
- Fixed plugin generation for Go 1.21
- Updated linting for Go 1.21
- Fixed minecraft example for Helm v3 pull download path
- Update dev docs to mention Go 1.21
- Regenerate plugins with Go 1.21
Related issues:
* https://github.com/kubernetes-sigs/kustomize/issues/5031
* https://github.com/kubernetes-sigs/kustomize/issues/5171
After noting this behaviour was not present in
d89b448c74 a `git bisect` pointed to the
change 1b7db20504. The issue with that
change is that upon seeing a `null` node it would replace it with a node
whose value was equivalent but without a `!!null` tag. This meant that
one application of a patch would have the desired approach: the result
would be `null` in the output, but on a second application of a similar
patch the field would be rendered as `"null"`.
To avoid this, define a new attribute on `RNode`s that is checked before
clearing any node we should keep. The added
`TestApplySmPatch_Idempotency` test verifies this behaviour.
See also https://github.com/kubernetes-sigs/kustomize/pull/5365 for an
alternative approach
* Allow importing kustomize API's without relying on `plugins`
Introduce `kustomize_disable_go_plugin_support` go build tag to decouple the kustomize
API from the `plugins` package dependency. This is advantageous for applications
embedding the kusstomize API without the need for dynamic Go plugins, mitigating an
increase in binary size associated with the inclusion of the plugins dependency
and the population of ELF sections like `.dynsym` and `.dynstr`.
The flag provides applications with the flexibility to exclude the import, catering to
scenarios where dynamic Go plugin support is unnecessary.
Signed-off-by: Tiago Silva <tiago.silva@goteleport.com>
* fix golint by disabling some lint checks
* handle code review suggestions
---------
Signed-off-by: Tiago Silva <tiago.silva@goteleport.com>
Kustomize sets the legacy KUSTOMIZE_PLUGIN_CONFIG_STRING and
KUSTOMIZE_PLUGIN_CONFIG_ROOT environment variables. When these
environment variables exceed a hardcoded length (PAGE_SIZE * 32 on most
Linux systems), the kernel will return `argument list too long`. Given
that the environment variables are legacy, log a warning and do not set
them if they exceed 131071 bytes.
Reported-at: https://github.com/kubernetes-sigs/kustomize/issues/5480
Signed-off-by: Andreas Karis <ak.karis@gmail.com>
For accumulation errors when the file load fails due to malformed
YAML and the base load fails due to a timeout, report both errors.
Previously only the malformed YAML error was returned, masking the
git repo timeout.
Add script to lookup component version from github releases.
To sort, we're using sort -V or --version-sort, depending which
option is available. This which has some limitations:
- pre-releases (-) are sorted as post-releases
- post-releases and build metadata (+) are ignored
This is the best option available for SemVer sorting without
requiring the user to install additional depedencies, like nodejs.
Add a blurb to the help output for both 'edit set configmap' and 'edit set secret'
to clarify that whenever a namespace is not specified, the default namespace is
implicitly defined as part of the commands.
* Add new functionality to allow editing a secret in a kustomization file. Initial
implementation supports only --from-literal option.
* Refactor edit set configmap to reuse some testing bits.
Copy package.json and package-lock.json into the site dev container
and use them to pin the versions and checksums for autoprefixer,
postcss-cli, and their dependencies.
This should help reduce risk of importing newer dependency versions
that haven't passed vulnerability checks.
* Add buildMetadata task and ref
Move build metadata tasks, draft buildMetadata reference
Clean up buildMetadata ref
Add managed by label task
Add local non-generated task
Add local generated resource
Add remote generator task
Clean up tasks and ref
Add local transformer annotation example
Add local and remote transformer example
* Address PR feedback and general cleanup
* * handle local flag
* add managerfactory handling for local flag
* add shortName handling for local flag
* add dot git file handling for local flag
* add tests
* fix normal listing
* add ParseGitRepository function, add viper, add testing for utils
* add latest tag logic, add auto pinning and auto fetching
* makke gorepomod list works with --local
* make pinning works with local flag, enable auto update on fork and non-fork repo
* fix: refactor to pass linter
* refactor code and fix comments
* edit README
* refactor code to pass linting
* refactor code
* refactor code and enable patch branch label
* ru add license
* fbackward compatibility for unpin
* Move the edit/remove_test/removetest.go file to the internal package, as it is
intended to aid testing.
* Rename the method ExecuteTestCases to ExecuteRemoveTestCases.
This reverts commit b692e49b1e.
The json-patch bump in k/k was reverted, so the corresponding bump in
kustomize should be reverted too.
Signed-off-by: Stephen Kitt <skitt@redhat.com>
* Add labels, annotations, namespaces, and names tasks
* Remove redundant information from ref/labels ref/annotations
* Update labels and annotations example names for consistency
* Remove name, prefix and suffix api examples
* Add link to tasks in reference
* Add link to tasks section for ref/configMapGenerator and ref/secretGenerator
* Add Labels/Annotatations headers
* Add Labels
* Add Template Labels
* Cleanup Add Template Labels
* Consolidate commonLabels and labels.includeSelectors
* Improve commonAnnotations example
* Add labels and annotations ref links
* Add generated ConfigMap to namespace example
* Add name headers
* Change header weights so they appear in sidebar
* Add namespace/name links
* Add generated ConfigMap to namePrefix example
* Add name propagation example
* Add more description of name propagation
* template labels
* Address feedback for labels
* Address names feedback
* Update for consistency
* Address feedback
* Remove API
Rename files that deal with configmaps and secrets to include the name of the
package as a prefix, as those were not following the pattern from the remaining
files in the package before.
* Fix a mistake in the comparison between elements in the ConfigMap and Secret args
test that causes it to become flaky.
* Rename the package in configmapSecretFlagsAndArgs_test.go back to util since the
testpackage linter has been disabled.
* fix patch.Target is nil in writePatchTargets
* add test case
* lint
* lint err not check
* remove new lin in imports
* rollback changes to `cmd :=`
* remove extra lines
* feat: add new command 'edit set configmap'
* Add a new command 'edit set configmap' to allow editing the values of an
already-existing configmap in a kustomization file.
* Add tests to validate the new feature.
* fix: add tests, minor refactoring to use constants
* Include tests to validade the new function ValidateSet, included to do
necessary validations when running the 'kustomize edit set configmap' command.
* Minor refactorings to use the existing constants in the 'edit set configmap'
command.
* Add dashes before each item in the comment explaining how ExpandFileSource()
works so IDEs don't try to reformat the list and remove the indentation in it.
* Because this change mutates the list of literal sources, ensure that both add
and set save the resulting list in a predictable order to make it easier to
check when new items are added/removed and aid in testing.
* Since literal sources are the only bit that's important in this test, verify
that the literal sources in the actual result is equal to what we expected it
to be.
* fix: change format to print resource name
Use '%q' formatter instead of '%s' to print resource name
Co-authored-by: Varsha <varshaprasad96@gmail.com>
* fix: add changes from code review
* Unexport constant that is used only in the scope of a single function.
* Add extra validation to ensure format is correct with one single '=' per key-value
pair.
* Add extra set of tests to validate format.
* Update test case to match new printed format in the error message.
* fix: rollback sort for edit add/set configmap
* chore: rename test package and unexport functions
Rename the test package from set_test back to set and unexport functions that do
not need to be exported anymore for testing purposes.
* feat: handle empty and default namespace as equal
Handle the empty and the default namespaces as equal. Add tests to validate this
scenario.
---------
Co-authored-by: Varsha <varshaprasad96@gmail.com>
Update the namespace handling in the edit add configmap and secret commands to
handle the empty namespace and the default namespace in the same way. Before
this change, if a configmap/secret was created using kustomize edit add where
one command was issued with default as the namespace and the other without a
namespace specified it would create two separate configmap generators, and then
kustomize build would fail if merge was not the strategy for either.
It makes sense to add that as a CLI args since you could use one single
kustomization file/helm chart for multiple clusters. Also it's easier to
have those on the CLI if the user has some kind of tooling that will end
up calling kustomize and that could pass those (i.e.: ArgoCD is doing
that for Helm so it could do that for Kustomize as well that will end up
calling Helm as well).
Signed-off-by: Arthur Outhenin-Chalandre <arthur.outhenin-chalandre@ledger.fr>
* Fix using same helm chart with different versions
* Fix p.ValuesFile when version is set
* Updated: Fix using same helm chart with different versions
* Add test for issue #4813
* Use if/else for readability, add version check to absChartHome
```shell
go work sync
for i in $(find . -name go.mod); do (cd $(dirname $i); go mod tidy); done
```
Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr>
* hotfix: return error instead of log at `FromMapAndOption`
* chore: show error message
* hotfix: use correct function
* hotix: use `t.Helper()` and fix `t *testing.T order
* hotfix: wrapt the error of `FromMapAndOption`
* hotfix: meaningful message for an error
* hotfix: summarize in one line
* hotfix: fix the abandoned error and show meaningful message
* hotfix: start with helper function
* Keep TODO comment
* Update tasks index description
* Create generators folder
* Update tasks/generators titles
* Add rollouts placeholder
* Add generate configmap from file example
* Add literals and env file example
* Add propogation example
* Consistent punctuation
* Update grammar
* Clean up configmaps page
* Remove examples from configMapGenerator ref page
* Move secret examples to Tasks
* Clean up spacing
* Consolidate cm and secret
* Consistent grammar
* Cleanup
* Address feedback
* Bump date
* Fix propagate spelling
* Remove roll out updates section
* Separate configmap and secret generator tasks
* Add secret from file example
* Add secret from literals example
* Update tls secret example
* Update task page weights
* Link cm generator reference
* Add link to secret reference
* Remove secretGenerator example from reference section
* Add configmap options task, clean up reference
* Add file with key example
* Secrets are base64 encoded
* Add the option to specify a namespace when using 'kustomize edit add configmap'
for code parity with 'edit add secret'.
* Rename constants for 'add configmap'/'add secret' so they are standardized.
* Create new constant for the 'namespace' flag.
* Update test cases to cover new scenarios.
* feat: minor refactoring + test improvements
* Refactor some bits of the edit add secret/configmap commands to reuse code.
* Improve test coverage for both these commands by invoking the cobra command
directly.
* Add some reusable constants for both these commands and their tests.
* fix: changes from code review
* Update formatting as requested in code review.
* Rename flagsAndArgs to configmapSecretFlagsAndArgs: change the file and struct
names to reflect the real usage of this code.
* Remove excessive newlines from the imports block.
* Replace all usages of assert with require and fix newlines in imports.
This PR intends to move the loader api to
internal. Only the necessary methods which
are needed for the api have been put into
`pkg/loader.go`.
Signed-off-by: Varsha Prasad Narsing <varshaprasad96@gmail.com>
Update the comment for the newCmdRemoveConfigMap function to explain what this
function really does. The previous comment was referring to a different function.
* Incorporate feedback from reviews.
* Add extra test cases to increase coverage.
* Tiny refactors for code parity with remove configmap.
* Update copyright notice.
```
===== ACTUAL BEGIN ========================================
apiVersion: v1
data:
config.yaml: "null"
kind: ConfigMap
metadata:
name: issue4905
===== ACTUAL END ==========================================
EXPECTED ACTUAL
-------- ------
apiVersion: v1 apiVersion: v1
data: data:
X config.yaml: |- config.yaml: "null"
X item1: 1 kind: ConfigMap
X item2: 2 metadata:
X kind: ConfigMap name: issue4905
X metadata:
X name: issue4905
hasgett.go:22: Expected not equal to actual
--- FAIL: TestHelmChartInflationGeneratorIssue4905 (0.24s)
```
Signed-off-by: Kazuki Suda <kazuki.suda@gmail.com>
* fix a patch files accept multiple patches
* fix comments and variable name
* add error handling when using not allowed multiple strategic-merge patches
* fix error message of Multiple Strategic-Merge Patch file
* refactor transformStrategicMerge()
* add TODO comment and test for Multiple JSON patch Yaml documents are not allowed
* refactoring PatchTransformer
* add multiple patch test for PatchTransformer package
* improve error message to PatchTransformer
* refactor const and error message check
* fix some error messages
* Restructure existing Reference docs
Restructure Reference section for site to better match k8s.io. Change
descriptions to complete sentences. Improve instructions to locally load
site.
* Document AnnotationsTransformer on site
Dcoument AnnotationsTransformer API under Reference on site.
* Document required fields
Document required fields and explain effects of optional ones.
* Make site setup instructions more explicit
* Link required K8s fields
* test: add openapi.IsNamespaceScoped benchmark
Add a benchmark test for IsNamespaceScoped performance when the default
schema is in use.
* perf: limit initSchema calls from openapi.IsNamespaceScoped
Avoid calling initSchema from openapi.IsNamespaceScoped when possible.
Work done in #4152 introduced a precomputed namespace scope map based on
the default built-in schema. This commit extends that work by avoiding
calls to initSchema when a resource is not found in the precomputed map
and the default built-in schema is in use. In those cases, there is no
benefit to calling initSchema since the precomputed map is exactly what
will be calculated by parsing the default built-in schema.
* fix: delay parsing of default built-in schema
When namespace scope can be determined by the precomputed map but the
type is not present in the precomputed map, delay the parsing of the
default built-in schema.
If the schema to be initialized is the default built-in schema and the
type is not in the precomputed map, then the type will not be found in
the default built-in schema. There is no need to parse the default
built-in schema for that answer; its parsing may be delayed until it
is needed for some other purpose.
In cases where the schema is used solely for namespace scope checks, the
schema might not ever be parsed. Skipping the parsing reduces both
execution time and memory use.
* fix: correct openapi.go's schemaNotParsed value
openapiData initializes with defaultBuiltInSchemaParseStatus set to 0,
so schemaNotParsed should have 0 as its value.
Kind:
Refactor
Summary:
Setters functionality is provided as a KRM function. We should remove code related to setters in cmd/config and kyaml.
As of now most setters2 and setters usage are related to fork of kpt, however, these:
[fluxcd/image-automation-controller](6827808a1a/pkg/update/filter.go (L24)) with [kyml](6827808a1a/go.mod (L42))
[rancher/fleet](0a6cf6cb92/internal/cmd/controller/controllers/image/update/setters.go (L16)) with [kyaml](0a6cf6cb92/go.mod (L75))
Repositories still using them, They pinned these two into a specific kyaml version. If we decide to go for this removal then we can make a release note that this is actually removed on the next version since we already marked this as deprecated before.
This PR is an effort towards internalizing public APIs.
It moves some of the builtinconstants to internal/
Signed-off-by: Varsha Prasad Narsing <varshaprasad96@gmail.com>
This PR is an effort towards reducing the public surface
of APIs. It move image/ to internal/image
Signed-off-by: Varsha Prasad Narsing <varshaprasad96@gmail.com>
(cherry picked from commit 1f5890709fdc17de6f44f42b5138dd0f7e64bc74)
This PR introduces go-api-diff checker in Makefile
and in CI to make sure we don't end up breaking APIs
unintentionally.
Signed-off-by: Varsha Prasad Narsing <varshaprasad96@gmail.com>
* Add accumulateResources error tests for local files.
Add tests demonstrating accumulateResources errors when the resource is
a local file. Works to address #4807.
* Improve readability
When a patch appends a new node, it should honor the key style from the
patch. Prior to this commit, no style was applied, leading to problems
when the key value could be interpreted as a different type based on its
content. For example, "9110" needs quoting to ensure it is seen as a
string in yaml.
* change: components apply after all generator and transformer applied
* fix name for a test case
* add comment about when the components will be executed
* components are applied before transformer
* Fix using same helm chart with different versions
* Fix p.ValuesFile when version is set
* Updated: Fix using same helm chart with different versions
* Add test for issue #4813
* Use if/else for readability, add version check to absChartHome
* return copied Node
* add a test case about imageTagTransformer for anchor scenario
* add TestPatchTransformerAnchor
* TestReplacementTransformerAnchor
Otherwise, a value consisting of a single quote character triggers a
panic:
go test krusty/configmaps_test.go
--- FAIL: TestDataIsSingleQuote (0.00s)
panic: runtime error: slice bounds out of range [1:0] [recovered]
panic: runtime error: slice bounds out of range [1:0]
Convert Gvk.ApiVersion() from using strings.Builder to raw string
concatenation. The logic in Gvk.ApiVersion() is simple enough that
raw concatenation executes quicker and consumes less memory.
* Update Versioning to Improve Output
* Always get commit from build info, always get date and version from ldflag
* Just replace broken main output with semver and deprecate short flag as is
---------
Co-authored-by: Katrina Verey <katrina.verey@shopify.com>
* support for more helm template args
* move templateArgs and unit tests to api/types
* undo package name change
* use our own simple helm chart instead of forking one
* add argument to AsHelmArgs
* code review
* lint errors
* Remove go module ci job
* Add script that runs go mod tidy with replace statements
* Invoke one script from the makefile and pass in the command to run in the pinned context
---------
Co-authored-by: Anna Song <annasong@google.com>
This commit optimizes in three ways:
1. For heavily used functions, allocate memory to avoid overhead
associated with map and array re-sizing.
2. Where appropriate, limit annotation and label retrievals to only the
desired keys.
3. Adjust annotation and label retrieval to avoid unnecessary temporary
object creation.
Add a short description of the namespace transformer and example
usage to examples/transformerconfigs/README.md.
References: #629
Signed-off-by: Lars Kellogg-Stedman <lars@oddbit.com>
* Ahead-of-time wildcard path expansion solution
* Wrapped PathGetter solution
This approach doesn't work when multiple existing sequence elements
should match, i.e. because the sequence contains maps and we're
searching on a key they all contain (target all containers with a certain
image would be one use case for this). PathGetter just takes the first
match in that case, which is not what we want.
* Add creation support to PathMatcher
* Regression test for existing bug when creation is enabled and sequence query should match multiple elements
* PathMatcher Create tests and support for sequence appending
* revert hyphen append support
PathGetter treats it as meaning 'last' not 'append' and does not have test coverage for its handling of this when create is set. Semantics are dubious given that multiple Replacement fieldPaths may be specified, which would cause successive appends.
* This also provides a solution to issue 1493
* Review feedback
* api: Add new types for customizeable resource ordering
Signed-off-by: Yannis Zarkadas <yanniszark@arrikto.com>
* plugins: Implement SortOrderTransformer plugin
Implement the SortOrderTransformer plugin. This plugin allows the user
to customize the order that kustomize will output resources in.
The API for the plugin is the following:
sortOptions:
order: legacy | fifo
legacySortOptions:
orderFirst:
- {GVK}
orderLast:
- {GVK}
Signed-off-by: Yannis Zarkadas <yanniszark@arrikto.com>
* plugins: Add boilerplate and generate code for new SortOrderTransformer
Signed-off-by: Yannis Zarkadas <yanniszark@arrikto.com>
* build: Add option to denote if the reorder flag was set by the user
We want to take different actions if the reorder flag was set by the
user or filled by the default value. Thus, we propagate this information
from build to the krusty options.
Signed-off-by: Yannis Zarkadas <yanniszark@gmail.com>
* api/krusty: Ensure sort ordering works with CLI flag and kustomization
Sort order can be defined in two places:
- (new) kustomization file
- (old) CLI flag
We want the kustomization file to take precedence over the CLI flag.
Eventually, we may want to move away from having a CLI flag altogether:
https://github.com/kubernetes-sigs/kustomize/issues/3947
Case 1: Sort order set in kustomization file AND in CLI flag.
Print a warning and let the kustomization file take precedence.
Case 2: Sort order set in CLI flag only or not at all.
Follow the CLI flag (defaults to legacy) and reorder at the end.
Case 3: Sort order set in kustomization file only.
Simply build the kustomization.
Signed-off-by: Yannis Zarkadas <yanniszark@gmail.com>
* krusty: Add e2e test for SortOrderTransformer
Signed-off-by: Yannis Zarkadas <yanniszark@arrikto.com>
* plugins: Purge LegacyOrderTransformer
Signed-off-by: Yannis Zarkadas <yanniszark@gmail.com>
* Update go.work.sum
Signed-off-by: Yannis Zarkadas <yanniszark@gmail.com>
* review: Make review changes
Signed-off-by: Yannis Zarkadas <yanniszark@gmail.com>
Signed-off-by: Yannis Zarkadas <yanniszark@arrikto.com>
Signed-off-by: Yannis Zarkadas <yanniszark@gmail.com>
* install_kustomize: support linux/aarch64, with fallback to old behavior
* shellcheck
* Comments from first review
* Comments from review
* Review comments: message consistency
This commit adds the `skipHooks` option to the helm chart support in order
to expose the --no-hooks flag introduced to Helm in [1].
Using Kustomize to inflate a Helm chart would in some situations result in
different results than using `helm install`. This is because `helm
template`, by default, will render chart tests in the `templates/test`
directory, which can lead to undesired resources in the output.
See [2] for additional discussion.
[1]: https://github.com/helm/helm/pull/6444
[2]: https://github.com/helm/helm/issues/6443
Signed-off-by: Lars Kellogg-Stedman <lars@oddbit.com>
* Better error message when git clone fails
* support file:// URLs
* rewrite remoteload_test
* lint and test fix
* fixes for kverey's comments
* document file:// remote load
* replace assert with require where appropriate
* add tests for file:// without git suffix
* fixes plus pr review from natasha
* fixes for review, lint
* revert changes to error handling
* fix skipped test
* rename overlays
* add further examples in first kustomization
* fix typo
* fix formatting
* fix typo
* fix formatting
* fix typos
* restore overlay names to production and staging in original content
* restore overlay names to production and staging in original content
* restore overlay names to production and staging in new content
* updated doc to use "you/your" vs "we/our", and updated to use US spelling
* fix capitalization
* Update site/content/en/docs/Getting started/first_kustomization.md
Co-authored-by: Katrina Verey <kn.verey@gmail.com>
* Update site/content/en/docs/Getting started/first_kustomization.md
Co-authored-by: Katrina Verey <kn.verey@gmail.com>
* add "patch:" for patches in kustomization, and add url link
* Update site/content/en/docs/Getting started/first_kustomization.md
Co-authored-by: Katrina Verey <kn.verey@gmail.com>
* fix typo
Co-authored-by: Katrina Verey <kn.verey@gmail.com>
* replacements: demonstrate broken behavior when using 'create: true' with an already existing field
* replacements: fix issue with 'create: true' option when there is an existing field
* Suggestion for PR 4667
* code review
* lint error
Co-authored-by: Katrina Verey <katrina.verey@shopify.com>
Otherwise, it is incompatible with filters like fieldSpec.Filter that recurse through a tree of RNodes. In the case of the bug this commit fixes, the leaf RNode is a metadata.annotation value field, and appendCsvAnnotation is called immediately before updating that leaf's value. If appendCsvAnnotation replaces the entire metadata.annotation RNode on the resource, the leaf RNode that gets updated is no longer attached to the resource.
Alternatively, `func (f Filter) setScalar` could be updated to change
the value of the leaf RNode BEFORE calling appendCsvAnnotation. However,
the modification of the entire metadata segment of the RNode in a
function that nominally just edits an annotation feels like a
side-effect prone to creating other difficult-to-debug situations,
beyond this ordering dependency.
* Move demandDirectoryRoot into kyaml/filesys
* Make root directory platform-agnostic
Support windows root directory. Dogfood own error package.
* Use cleaner windows support implementation
* Address feedback
* Address feedback x2
* Re-apply go.sum changes to avoid CI errors
* Switch github.com/xlab/treeprint to release tag : v1.1.0
Signed-off-by: Davanum Srinivas <davanum@gmail.com>
* fix test to reflect changes in the dependency
Signed-off-by: Davanum Srinivas <davanum@gmail.com>
* Propose kustomize localize
Write mini KEP proposal for new command kustomize localize.
* Incomplete commit
* Update proposal based on Katrina's feedback
Changes are summarized in comments in PR
* Address feedback in comments
* fix containerized function mounts issue
* skip path test on windows
* move test out of temp dir
* update tests to deal with new working dir restrictions
* code review
* update necessary dependencies
* update openapi test structure
* remove old swagger files and generate new ones
* use protobuffer to parse openapi for performance improvement
* test: use `T.TempDir` to create temporary test directory
This commit replaces `ioutil.TempDir` with `t.TempDir` in tests. The
directory created by `t.TempDir` is automatically removed when the test
and all its subtests complete.
Prior to this commit, temporary directory created using `ioutil.TempDir`
needs to be removed manually by calling `os.RemoveAll`, which is omitted
in some tests. The error handling boilerplate e.g.
defer func() {
if err := os.RemoveAll(dir); err != nil {
t.Fatal(err)
}
}
is also tedious, but `t.TempDir` handles this for us nicely.
Reference: https://pkg.go.dev/testing#T.TempDir
Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
* test: fix `TestInit_noargs` on Windows
--- FAIL: TestInit_noargs (0.01s)
testing.go:1090: TempDir RemoveAll cleanup: remove C:\Users\RUNNER~1\AppData\Local\Temp\TestInit_noargs3136084632\001: The process cannot access the file because it is being used by another process.
Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
* test: fix `TestTreeCommandDefaultCurDir_files` on Windows
--- FAIL: TestTreeCommandDefaultCurDir_files (0.01s)
testing.go:1090: TempDir RemoveAll cleanup: remove C:\Users\RUNNER~1\AppData\Local\Temp\TestTreeCommandDefaultCurDir_files716679291\001: The process cannot access the file because it is being used by another process.
Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
* test: fix `TestCreateSetterCommand` on Windows
--- FAIL: TestCreateSetterCommand (13.27s)
--- FAIL: TestCreateSetterCommand/add_replicas (1.45s)
testing.go:1090: TempDir RemoveAll cleanup: remove C:\Users\RUNNER~1\AppData\Local\Temp\TestCreateSetterCommandadd_replicas176222064\001\k8s-cli-487197005.yaml: The process cannot access the file because it is being used by another process.
...
and all subtests
...
Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
* test: fix `TestCreateSubstitutionCommand` on Windows
--- FAIL: TestCreateSubstitutionCommand (4.16s)
--- FAIL: TestCreateSubstitutionCommand/substitution_replicas (1.30s)
testing.go:1090: TempDir RemoveAll cleanup: remove C:\Users\RUNNER~1\AppData\Local\Temp\TestCreateSubstitutionCommandsubstitution_replicas1352417113\001\k8s-cli-3183612276.yaml: The process cannot access the file because it is being used by another process.
...
and all subtests
...
Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
* test: fix `TestDeleteSetterCommand` on Windows
--- FAIL: TestDeleteSetterCommand (4.36s)
--- FAIL: TestDeleteSetterCommand/delete_replicas (1.31s)
testing.go:1090: TempDir RemoveAll cleanup: remove C:\Users\RUNNER~1\AppData\Local\Temp\TestDeleteSetterCommanddelete_replicas3949811929\001\k8s-cli-957077271.yaml: The process cannot access the file because it is being used by another process.
...
and all subtests
...
Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
* test: fix `TestDeleteSubstitutionCommand` on Windows
--- FAIL: TestDeleteSubstitutionCommand (2.35s)
--- FAIL: TestDeleteSubstitutionCommand/delete_only_subst_if_setter_has_same_name_-_long_ref (1.15s)
testing.go:1090: TempDir RemoveAll cleanup: remove C:\Users\RUNNER~1\AppData\Local\Temp\TestDeleteSubstitutionCommanddelete_only_subst_if_setter_has_same_name_-_long_ref2039728641\001\k8s-cli-1602861478.yaml: The process cannot access the file because it is being used by another process.
...
and all subtests
...
Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
* test: fix `TestSetCommand` on Windows
--- FAIL: TestSetCommand (13.76s)
--- FAIL: TestSetCommand/set_replicas (1.13s)
testing.go:1090: TempDir RemoveAll cleanup: remove C:\Users\RUNNER~1\AppData\Local\Temp\TestSetCommandset_replicas3781384539\001\k8s-cli-1030344459.yaml: The process cannot access the file because it is being used by another process.
...
and all subtests
...
Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
* add tagsuffix to take image tag suffix
* add comments to warn about specifications
* add test and error handle
* fix indent
* update comment
* fix merge errors and return updates
* update image update and fix example
* fix yamls formats
remove tabs in yamls
fix space in image name
tag error in name
* fix spacing issue
format of yaml
set example as above
* spacing of spec in testing templates
* change to switch case
* Raise error if duplicate orgids for external transformers or external generators are configured
* Remove output of resources in error message
* Remove trailing newline
* check tag values for double quoting
* reuse setentry
* don't override single quotes in merge and fix cm generator immutable val
* get rid of comment
* starlark annotation tests
* don't commit test image changes
* set network to bool
* isSet bool
* updating e2e config tool
* leave createtag
* fn command failing unmarshal test
* fn command test
* don't set style in run-fs
* use setentry to set tag
* remove e2e test changes and make IsStringValue an RNode method
* WIP
* Fix merge corner cases
* Add test for explicit !!merge tag
* Fix tests
* Cleanup
* Cleanup
* Fix deanchoring lists
* Add test case for keeping comments
* Add MapEntrySetter and fix json marshalling after deanchoring
* Keep duplicated keys
* Move MergeTag definition to yaml alias
* Remove go-spew from api
* Add support for sequence nodes on merge tags
* Add docstring to MapEntrySetter.Key
* Add docstring to MapEntrySetter struct
* Add tests to MapEntrySetter
* Fix duplicate merge key
* Revert whitespace changes on forked go-yaml
* Remove AssocMapEntry function
* Refactoring merge order
* Return errors on VisitFields and PipeE
* Add tests for each non-conforming map merges
Erasing the scalar type tag leads to unfortunate circumstances, in that
the resulting yaml code is valid yaml, but will not meet the object
spec.
For example, using the replacement transformer to take a port number as
a string from a ConfigMap and set a Pod port would previously end up
with:
- containerPort: "8080"
when the spec requires that this is not a string:
- containerPort: 8080
Added unit tests for conversion to and from integers and booleans, plus
creation from string and creation from integer.
The creation behavior needs some refinement in a future PR.
Signed-off-by: Jim Ramsay <i.am@jimramsay.com>
* Fix image name parsing with name and digest
Image names may contain both tag name and digest. For example
`nginx:1.21.5@sha256:7826426c9d8d310c62fc68bcd5e8dde70cb39d4fbbd30eda3b1bd03e35fbde29`. Kustomizations with image transforms will not match
these image because the image parser assumes either a tag or digest, but not
both.
For a real life example of kuberenetes deployments that might need to perform
these types of transforms is from the [tekton-pipelines](https://github.com/tektoncd/pipeline) project (see the release.yaml).
* Return digest property from image name parser
image.Split now returns 3 fields: name, tag, and digest. The tag and digest
fields no longer include their respective delimiters (`:` and `@`).
* Fix merge file indentation
* Refactor imagetag updater string builder
This change updates the suffix filter to implement the TrackableFilter
interface. This provides the functionality for the user to track which
fields were updated by the suffix filter.
This change updates the replicacount filter to implement the
TrackableFilter interface. This provides the functionality for the
user to track which fields were updated by the replicacount filter.
This change updates the prefix filter to implement the TrackableFilter
interface. This provides the functionality for the user to track which
fields were updated by the prefix filter.
This change updates the namespace filter to implement the TrackableFilter
interface. This provides the functionality for the user to track which
fields were updated by the namespace filter.
This change provides a common test util for a mutation tracker stub.
This is intended to reduce the duplicated boilerplate as additional
filters implement the TrackableFilter interface.
The FieldPath was not being set for nodes underneath a SequenceNode
during fieldspec's traversal. This is in part because handleSequence
uses VisitElements in contrast to a PathGetter as is done by handleMap.
The accuracy of FieldPath is more relevant now with the recently added
support of mutation trackers in filtersutil. This change fixes the
case where a mutation tracker callback is called on a SequenceNode
element and the node does not have an accurate FieldPath value.
This change updates the imagetag filter to implement the TrackableFilter
interface. This provides the functionality for the user to track which
fields were updated by the imagetag filter.
This change refactors imagetag to reuse the abstraction provided by
filtersutil. This change is intended to make imagetag more consistent
with other filters by using the same layer of abstraction (filtersutil),
and to prepare for upcoming changes which are planned to be implemented
at the filtersutil layer.
* add kio filter interface
This interface is an extension of the Filter interface which can be used
for filters which are capable of tracking which fields they mutate.
* add TrackableSetter struct to filtersutil
This struct provides an abstraction to help Filters implement the
TrackableFilter interface
* implement TrackableFilter with annotations
This updates the annotations filter to implement the TrackableFilter
interface by reusing the TrackableSetter abstraction provided by
filtersutil.
This is done to provide a generic and consistent experience across the
filters
* implement TrackableFilter with labels
This updates the labels filter to implement the TrackableFilter
interface by reusing the TrackableSetter abstraction provided by
filtersutil.
This is done to provide a generic and consistent experience across the
filters
Add a configurable callback that is invoked each time a label is applied
by the labels filter. This is useful for scenarios such as tracking
labels as they are applied.
* add origin annotation for resources generated by builtin and custom generators
* decouple origin data from generator data and account for inline generators
* Refactor prefix filter into its own filter, decoupled from the prefixsuffix filter
* Refactor prefix transformer into its own transformer, decoupled from the prefixsuffix transformer
* Refactor suffix filter into its own filter, decoupled from the prefixsuffix filter
* Refactor suffix transformer into its own transformer, decoupled from the prefixsuffix transformer
* Add a default nameSuffix field spec in addition to the namePrefix
* Remove the PrefixSuffixTransformer from the list of builtin transformers
* Add a multi-transformer to builtinhelpers.TransformFactories
* Remove the implementation of the prefixsuffixtransformer.PrefixSuffixTransformer
* Resolve style and format related feedback from the pull request
* Add test to test the legacy PrefixSuffixTransformer for BC purposes
When using the ConfigMap generator, a lease object entry is updated with the
generated configmap name. This should not happen as it's an unrelated object
type.
As a workaround a unique name can be used for the ConfigMap.
Fails on kustomize version 4.2.0 and kubectl version v1.21.2
GitHub release files like https://github.com/fluxcd/helm-controller/releases/download/v0.14.0/helm-controller.crds.yaml
seems to be hosted on Azure and it seems that there are egress limits that can be reached, e.g.:
```xml
<?xml version="1.0" encoding="utf-8"?><Error><Code>ServerBusy</Code><Message>Egress is over the account limit.
RequestId:f4a46b38-001e-0046-2437-ec16e2000000
Time:2021-12-08T13:28:03.8542138Z</Message></Error>
```
This patch allows to have a clear Error message instead of just `missing Resource metadata`:
```
Error: accumulating resources: accumulation err='accumulating resources from 'https://github.com/fluxcd/source-controller/releases/download/v0.19.0/source-controller.crds.yaml': URL returned error 503 (Service Unavailable)': evalsymlink failure on '/private/var/folders/hq/ttl6jyh539q55fz6282w0jyc0000gn/T/kustomize-3508224975/releases/download/v0.19.0/source-controller.crds.yaml' : lstat /private/var/folders/hq/ttl6jyh539q55fz6282w0jyc0000gn/T/kustomize-3508224975/releases: no such file or directory
```
Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr>
The Pipe method is not as intuitive as these helpers. These helpers
are convenient and useful. Deprecating them before we have better
alternatives is premature.
Add a configurable callback that is invoked each time an
annotation is applied by the annotations filter. This is useful
for scenarios such as tracking annotations as they are applied.
Issues: GoogleContainerTools/kpt#2448
- Result can only count as error when passed as pointer, this makes easy use of "errors.As"
- Existing Filter() implementations that return Result from the `framework` package won't return an error anymore but modify the ResourceList
Updates the example for patching multiple objects to match the
implementation in #1355, which supports name as a regular expression
(not wildcard pattern).
Resources annotated as "local-config" are expected to be ignored. This skip local resource happens in "accumulateResources" which happens before any transformation operations.
However, the local resource may be needed in transformations.
Thus, this change removes the "drop local resource" logic from accumulateResources and removes these local resource after all transformation operations and var operations are done.
Note:
None of the existing ResMap functions can drop the resource slice easily: "Clear" will ruin the resource order, "AppendAll" only adds non-existing resource, "AbsorbAll" only add or modify but not delete.
Thus, we introduce a new func "Intersection" for resourceAccumulator that specificaly removes the resource by ID and keep the original order.
* Precompute IsNamespaceScoped to avoid expensive schema reads
See https://github.com/GoogleContainerTools/kpt/issues/2469
For the `gcr.io/kpt-fn/set-namespace:v0.1` function, over 50% of CPU
time is spent on IsNamespaceScoped. Instead of unmarshalling 100k lines
of JSON to determine this, instead just precompute it. We can ensure
this never is inaccurate as the test verifies the precomputed result is
up to date.
In real world kpt pipelines this cuts execution of set-namespace (and
similar functions, just an example of a trivial function) from 2.0s to
1.0s. Because these functions are run in long pipelines over many
resources, this adds up a lot.
* Add documentation
Because this is in an inner loop and is fairly memory-allocation
expensive even on a single allocation, it comes up top-of-the-list in
memory allocation pprof profiles, for example with the coredns
ClusterAddon.
Add simple caching.
* exec function working dir is the kustomization that referenced it
* suggested changes
* more code review
* use a field instead of an annotation
* more code review
* Add edit set annotation feature
* Apply suggested code improvements
* Apply suggested changes
* Fix regex, add more tests
* Add constant for common error message
* Fix too many characters per line error
* Use string concatenation instead, add FailNow call
* Expand documentation of annotations used in manifests and KRM function wire format.
- Reserve `internal.config.kubernetes.io` for control annotations
- Document `local-config` annotation in a seperate document (It's
orthogonal to KRM functions).
- There is a internal annotation that uses `config.k8s.io` instead of
`config.kubernetes.io` used by other annotations. See [1] and [2]. We
should avoid using two seperate annotation prefixes and audit the
codebase for any other annotation. Given the `id` control annotation is used
for comment preservation (no existing function should be modifying
it), I suggest moving this over to use
`fn-ctrl.config.kubernets.io/id`.
[1]: 7e8ba62e9f/kyaml/fn/runtime/runtimeutil/runtimeutil.go (L195)
[2]: https://github.com/kubernetes-sigs/kustomize/pull/2465
* Move path/index annotation to use internal prefix
* Clarify MUST NOT vs SHOULD NOT for internal annotations
* Update cmd/config/docs/api-conventions/functions-spec.md
Co-authored-by: Katrina Verey <kn.verey@gmail.com>
* Update cmd/config/docs/api-conventions/functions-spec.md
Co-authored-by: Katrina Verey <kn.verey@gmail.com>
* Update cmd/config/docs/api-conventions/manifest-annotations.md
Co-authored-by: Katrina Verey <kn.verey@gmail.com>
* Remove kusotmization as example
Co-authored-by: Katrina Verey <kn.verey@gmail.com>
* Move api/filesys to kyaml/filesys
* Add deprecated version of api/filesys with aliases to new code
* Use new kyaml/filesys package and update dependencies
* Migrate to kyaml/filesys and update dependencies
* Skip tests that break on Windows
Please provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner.
If this matter is security related, please disclose it privately via https://kubernetes.io/security
validations:
required:true
- type:textarea
id:expected
attributes:
label:What did you expect to happen?
validations:
required:true
- type:textarea
id:repro-files
attributes:
label:How can we reproduce it (as minimally and precisely as possible)?
description:Please provide a minimum set of files that can reproduce the issue. You can paste the file contents here or provide a link to a tarball or git repo. Even better, submit a tests case in the api/krusty package! For more information on how to do that, see https://kubectl.docs.kubernetes.io/contributing/kustomize/bugs/.
value:|
```yaml
# kustomization.yaml
apiVersion:kustomize.config.k8s.io/v1beta1
kind:Kustomization
resources:
- resources.yaml
```
```yaml
# resources.yaml
apiVersion:v1
kind:ConfigMap
metadata:
name:test-object
data:
placeholder:data
```
validations:
required:true
- type:textarea
id:expected-output
attributes:
label:Expected output
description:If you are able to provide reproduction files, please include the output you expect here.
value:|
```yaml
```
validations:
required:false
- type:textarea
id:actual-output
attributes:
label:Actual output
description:If you are able to provide reproduction files, please include the output they currently produce here.
value:|
```yaml
```
validations:
required:false
- type:input
id:kustomize-version
attributes:
label:Kustomize version
description:Please use the latest version whenever possible.
placeholder:What version of Kustomize are you using?
Small, straightforward enhancements can be proposed in regular GitHub issues using the template below. As a rule of thumb, the enhancement should be resolvable in a single PR that is at most size L. Anything more involved requires a mini (in-repo) enhancement proposal, and features with implications for kubectl require a full [KEP](https://github.com/kubernetes/enhancements).
For more information on the Kustomize enhancement process, see: https://github.com/kubernetes-sigs/kustomize/tree/master/proposals.
When in doubt, go ahead and fill out the template below; the maintainers will let you know if a KEP is required.
- type:checkboxes
attributes:
label:Eschewed features
description:Some features are out of scope for Kustomize because they are incompatible with its foundational design principles. Please review the [Eschewed Features](https://kubectl.docs.kubernetes.io/faq/kustomize/eschewedfeatures/) documentation before submitting your feature request.
options:
- label:This issue is not requesting templating, unstuctured edits, build-time side-effects from args or env vars, or any other eschewed feature.
required:true
- type:textarea
id:feature-description
attributes:
label:What would you like to have added?
validations:
required:true
- type:textarea
id:rationale
attributes:
label:Why is this needed?
validations:
required:true
- type:textarea
id:current-alternatives
attributes:
label:Can you accomplish the motivating task without this feature, and if so, how?
validations:
required:true
- type:textarea
id:design-alternatives
attributes:
label:What other solutions have you considered?
validations:
required:true
- type:textarea
id:additional-info
attributes:
label:Anything else we should know?
validations:
required:false
- type:checkboxes
attributes:
label:Feature ownership
description:The Kustomize project, like many areas of Kubernetes, currently lacks enough contributors to adequately respond to all proposals that have merit. Offering to build and support the feature yourself can help get traction for your request.
options:
- label:I am interested in contributing this feature myself! 🎉
[MacOS Dev Guide]: https://kubectl.docs.kubernetes.io/contributing/kustomize/mac/
[Windows Dev Guide]: https://kubectl.docs.kubernetes.io/contributing/kustomize/windows/
# Contributing Guidelines
Welcome to Kubernetes. We are excited about the prospect of you joining our [community](https://github.com/kubernetes/community)! The Kubernetes community abides by the CNCF [code of conduct](code-of-conduct.md). Here is an excerpt:
Welcome to Kubernetes. We are excited about the prospect of you joining our [community](https://github.com/kubernetes/community)! The Kubernetes community abides by the [CNCF Code of Conduct]. Here is an excerpt:
_As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities._
## Getting Started
Dev guides:
### Forking Kustomize and Working Locally
The Kustomize project uses a "Fork and Pull" workflow that is standard to GitHub. In git terms, your personal fork is referred to as the "origin" and the actual project's git repository is called "upstream". To keep your personal branch (origin) up to date with the project (upstream), it must be configured within your local working copy.
- [Contributor License Agreement](https://git.k8s.io/community/CLA.md) Kubernetes projects require that you sign a Contributor License Agreement (CLA) before we can accept your pull requests
- [Kubernetes Contributor Guide](http://git.k8s.io/community/contributors/guide) - Main contributor documentation, or you can just jump directly to the [contributing section](http://git.k8s.io/community/contributors/guide#contributing)
- [Contributor Cheat Sheet](https://git.k8s.io/community/contributors/guide/contributor-cheatsheet/README.md) - Common resources for existing developers
You will need to periodically fetch changes from the `upstream` repository to keep your working branch in sync.
```bash
cd kustomize
git fetch upstream
git checkout myfeature
git rebase upstream/master
```
### Push to GitHub
When your changes are ready for review, push your working branch to your fork on GitHub.
```bash
cd kustomize
git push origin myfeature
```
### Pull Request Rules
We are using [Conventional Commits v1.0.0](https://www.conventionalcommits.org/en/v1.0.0/) as the main guideline of making PR. This guideline serves to help contributor and maintainer to classify their changes, thus providing better insight on type of release will be covered on each Kustomize release cycle.
1. Please add these keywords on your PR titles accordingly
| Keyword | Description | Example |
| ------------- | ------------- | ------------- |
| fix | Patching or fixing bugs or improvements introduction from previous release. This type of change will mark a `PATCH` release. | fix: fix null value when generating yaml |
| feat | New features. This change will mark a `MINOR` release. | feat: new transformer and generator for ACME API CRD. |
| chore | Minor improvement outside main code base | chore: add exclusion for transformer test. |
| ci | CI/CD related changes (e.g. github workflow, scripts, CI steps). | ci: remove blocking tests |
| docs | Changes related to documentation. | docs: add rules documentation for PR. |
2. Add `BREAKING CHANGE:` on your commit message as footer to signify breaking changes. This will help maintainers identify `MAJOR` releases.
Example:
```
feat: change YAML parser from `yaml/v1` to `yaml/v2`
BREAKING CHANGE: parse() function now works with 2 arguments.
```
### Create a Pull Request
1. Visit your fork at `https://github.com/<user>/kustomize`
2. Click the **Compare & Pull Request** button next to your `myfeature` branch.
3. Check out the pull request [process](https://github.com/kubernetes/community/blob/master/contributors/guide/pull-requests.md) for more details and advice.
If you ran `git push` in the previous step, GitHub will return a useful link to create a Pull Request.
### Build Kustomize
The [Kustomize Architecture] document describes the respository organization and the kustomize build process.
```bash
# For go version >= 1.13
unset GOPATH
unset GO111MODULES
# Build kustomize binary and install in go bin path
cd kustomize
make kustomize
# Run unit tests
make test-unit-all
# Run linter
make lint
# Test examples against HEAD
make test-examples-kustomize-against-HEAD
# Run your development version
~/go/bin/kustomize version
```
### General resources for contributors
- [Contributor License Agreement] - Kubernetes projects require that you sign a Contributor License Agreement (CLA) before we can accept your pull requests.
- [Kubernetes Contributor Guide] - Main contributor documentation.
- [Contributor Cheat Sheet] - Common resources for existing developers.
Here are some additional ideas to help you get started with Kustomize:
- Attend a Kustomize Bug Scrub. Check the [SIG-CLI] meetings list to find the next one.
- Help triage issues by confirming validity and applying the appropriate `kind` label (e.g. comment `/kind bug`).
- Pick up an issue to fix. Issues with the `help-wanted` label are a good place to start, but you can also look for any issue with the `triage/accepted` label and no assignee. Remember to `/assign` yourself to let others know you're working on it.
- Help confirm new issues labelled `kind/bug` by reproducing them with the latest release.
- Support Kustomize users by responding to questions on issues labelled `kind/support` or in the [Slack channel].
## Mentorship
@@ -22,19 +151,154 @@ We have full documentation on how to get started contributing here:
## Contributor Ladder
Kustomize generally follows the [Kubernetes Community Membership](https://github.com/kubernetes/community/blob/master/community-membership.md) contributor ladder. Roles are as follows:
Kustomize follows the [Kubernetes Community Membership] contributor ladder. Roles are as follows:
1. Contributor: Anyone who actively contributes code, issues or reviews to the project. There are no Kustomize-specific requirements for this status. All contributors must [sign the CLA](https://github.com/kubernetes/community/tree/master/contributors/guide#prerequisites).
1.Member/Reviewer: All Kubernetes-SIGs org members have LGTM rights on the Kustomize repo. There are no Kustomize-specific requirements. Kustomize does not currently have any formal reviewers, but the role will be created if there is interest.
1.Maintainer/Approver: Highly experienced active reviewer and contributor to Kustomize. Has both LTGM and approval rights on the Kustomize repo, as well as [Github "maintain" rights](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-permission-levels-for-an-organization#repository-access-for-each-permission-level).
1.Admin/Owner: Maintainer who sets technical direction and makes or approves design decisions for the project. Has LGTM and approval rights on the Kustomize repo as well as [Github "admin" rights](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-permission-levels-for-an-organization#repository-access-for-each-permission-level).
1. Contributor: Anyone who actively contributes code, issues or reviews to the project. All contributors must sign the [Contributor License Agreement].
1. Reviewer: Contributors with a history of review and authorship on Kustomize. Has LGTM rights on the Kustomize repo (as do all kubernetes-sigs org members). Active contributors are encouraged to join the reviewers list to be automatically pinged on PRs.
1. Approver: Highly experienced active reviewer and contributor to Kustomize. Has both LTGM and approval rights on the Kustomize repo, as well as "maintain" [Github permissions].
1. Owner: Approver who sets technical direction and makes or approves design decisions for the project. Has LGTM and approval rights on the Kustomize repo as well as "admin" [Github permissions].
Administrative notes:
- Maintainers and admins must be added to the appropriate list both [in the Kustomize repo](https://github.com/kubernetes-sigs/kustomize/blob/8049f7b1af52e8a7ec26faf6cf714f560d0043c5/OWNERS_ALIASES) and [in the community repo](https://github.com/kubernetes/org/blob/main/config/kubernetes-sigs/sig-cli/teams.yaml). If this isn't done, the individual in question will lack either PR approval rights (Kustomize list) or the appropriate Github repository permissions (community list).
- The spec for the OWNERS file is [in the community repo](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md).
The kyaml module within the Kustomize repo has additional owners following the same ladder.
For the kustomize project, we have defined some specific guidelines on each step of the ladder:
To reach reviewer status, you must:
- Have been actively involved in kustomize for 3+ months
- Review at least 8 PRs that have been driven through to completion (see the reviewer guide below)
- Author at least 5 PRs that have been approved and merged
- Be a member of the kubernetes-sigs org. This should not be a blocker though, as once you meet the requirements for reviewer here,
the existing kustomize maintainers will be happy to sponsor your request to join the kubernetes-sigs org.
- Once you have met the above requirements, you may submit a PR adding yourself to the kustomize reviewers list, with links to your
contributions in the description.
To reach approver status, you must:
- Meet all the requirements of a reviewer
- Have been actively involved in kustomize for 6+ months
- Review at least 15 PRs that have been driven through to completion (see the reviewer guide below)
- Authored PRs meeting *either* of the following requirements:
- 15 PRs that have been approved and merged
- *OR* 10 PRs that have been approved and merged where some were more difficult, required greater thought/design,
or built up to larger features/long-term goals.
- File 3 issues. This can be any number of things, including but not limited to:
- Bugs with kustomize usage that you've found
- CI or release improvements
- Creating subtasks of a larger feature or project that you are in charge of.
- Long term improvements for the health of the project
- Triage at least 10 untriaged issues, including at least 1 feature request. The kustomize bug scrub is a great place to get practice with doing this, but you can
also follow the triage guide below to get started on your own.
- Demonstrate deeper understanding of kustomize goals. This can take many forms and is a bit subjective, but here are a few examples:
- saying no to an eschewed feature, instead recommending an alternative solution that is more aligned with the declarative configuration model
- active participation in discussion on a feature request issue
- filing an issue describing a long term problem and solution aligned with kustomize goals, for example: https://github.com/kubernetes-sigs/kustomize/issues/5140
- writing up KEPs for features that will improve the kustomize workflow while being aligned with kustomize goals, for example: https://github.com/kubernetes-sigs/kustomize/pull/4558
- Regularly interact with the existing kustomize maintainers, with clear communication about what you are working on or planning to work on. The kustomize
maintainers should know who you are and be familiar with your contributions.
- If you meet *most* of the above requirements while going above and beyond in a few areas, we will still consider your request to become an approver even
if you are missing one or two of the requirements. Please contact the maintainers directly to ask about getting approver status if you fall into this category.
- Otherwise, once you meet all the above requirements, you may:
- request to be added to the kustomize maintainer meeting that occurs each week with the kustomize PMs.
- submit a PR adding yourself to the kustomize approvers list, with links to your contributions in the description.
To reach owner status, you must:
- Meet all the requirements of an approver
- Have been actively involved with kustomize for 1+ year
- Assisted the current owner in driving the roadmap. This can be explicit or implicit help, such as:
- Editing the roadmap directly
- Reviewing the roadmap
- Providing suggestions for issues or prioritization in meetings that indirectly influence the roadmap
- Regularly triage issues and attend the kustomize bug scrub
- Regularly review PRs (1-2 a week)
- Periodically lead the kustomize bug scrub
- Periodically release kustomize (ensuring that there are no release blockers and that release notes are clean)
- Be the primary owner or point of contact for a particular project or area of code
- Ideally, there should be 2-3 owners at a time. Reach out to the current owners if you are interested in ownership. These
requirements are not strict and evaluation is somewhat subjective.
## Reviewer guide
Please watch this talk on how to review code from Tim Hockin: https://www.youtube.com/watch?v=OZVv7-o8i40
For reviewing PRs in kustomize, we have some specific guidelines:
- If the PR is introducing a new feature:
- *It must be implementing an issue that has already been triage/accepted or
a KEP that has been approved.* If it is not, then request the PR author to first file an issue.
- The PR must include thorough tests for the new feature, including unit and integration tests
- The code must be clean and readable, with thought given to how we will maintain the code in the future
- If the feature requires being broken up into multiple PRs to ease review, the feature should not be exposed to users
until the feature is completed in the last PR. For example, while we were building `kustomize localize`, we
built the feature almost entirely under the `api` module as a library with all the needed tests. There was no way
for users to invoke the localize code until the last PR that actually exposed the `kustomize localize` command in the
kustomize binary. This allowed us to continue development of `kustomize localize` without blocking kustomize releases.
If this type of development is not possible, then new features requiring multiple PRs should be
developed in their own feature branch.
- If the PR is introducing a bug fix:
- If the PR is not fixing an issue that has already been triage/accepted, follow the triage guide below on bug
fixes to decide if this is a PR we want to accept.
- The PR should have two distinct commits:
- The first commit should add a test demonstrating incorrect behavior
- The regression test is absolutely required, and we cannot accept bug fixes without tests.
- If the PR is introducing a performance improvement:
- The PR description should give an indication of how much the performance is being improved and how we
can measure it - benchmark tests are fantastic.
- Other PRs (documentation, CI improvements, etc.) should be reviewed based on your best judgment.
## Triage guide
The possible triage labels are listed here: https://github.com/kubernetes-sigs/kustomize/labels?q=triage.
Triaging a feature request means:
- Understand what the user is asking for, and their use case.
- Verify that it is not an [eschewed feature](https://kubectl.docs.kubernetes.io/faq/kustomize/eschewedfeatures/#build-time-side-effects-from-cli-args-or-env-variables)
- Verify that it is not a duplicate issue.
- Look into workarounds. Is there another way that the user can achieve their use case with existing features?
- If you are new to this role, prior to leaving a comment on the issue, please bring it to weekly standup
for group discussion to make sure that we are all on the same page.
- Once you feel ready, you can label it with a triage label. Here's an [example](https://github.com/kubernetes-sigs/kustomize/issues/5049). You can also
look at other feature request issues to see how they were triaged and resolved. There are a few different triage labels that you can use, you can see the
full list [here](https://github.com/kubernetes-sigs/kustomize/labels?q=triage).
Triaging a bug means:
- First, verify that you can reproduce the issue. If you cannot reproduce the issue or need more information to give
it a go, triage it accordingly.
- Try to understand if this is really a bug or if this is intended behavior from kustomize. If it seems like intended
behavior, do your best to explain to the user why this is the case.
- If it seems to be a genuine bug, you can /triage accept the issue. In addition, investigate if there are workarounds or
alternative solutions for the user that they can try until the issue gets resolved.
The triage party for kustomize is here https://cli.triage.k8s.io/s/kustomize and can be a easy way to
find issues that have not been triaged yet.
## Project/Product Managers
Kustomize will have opportunities to join in a project/product manager role. You can reach out to
the existing kustomize maintainers if you are interested in this type of role. Project management work
can greatly help supplement your contributions as you climb from reviewer to approver
to owner.
Expectations for this role are:
- Triage 1 feature request each week, and bring it to weekly stand-up for discussion. Feature
requests are issues labeled kind/feature, and you can find them [here](https://github.com/kubernetes-sigs/kustomize/issues?q=is%3Aissue+is%3Aopen+kind+feature+label%3Akind%2Ffeature).
Please view the above triage guide for details on how to approach feature request triage.
- Monitor the kustomize Slack channel and try to help users if you can. It is a pretty
active channel, so responding to 4-5 users per week is sufficient even if some
questions go unanswered. If there is an interesting topic or a recurring problem that many
users are having, please bring it up in weekly stand-up.
- Keeping track of a queue of backlog issues or PRs that are not being actively looked at in any existing project board.
- Organizing or reorganizing project tracking boards when it makes sense.
You will also be asked to help with roadmap planning, deprecation communication, prioritization,
and doing research on kustomize usage when appropriate, though these responsibilities will occur less
frequently.
## Administrative notes:
- The [OWNERS file spec] is a useful resources in making changes.
- Maintainers and admins must be added to the appropriate lists in both [Kustomize OWNERS_ALIASES] and [SIG-CLI Teams]. If this isn't done, the individual in question will lack either PR approval rights (Kustomize list) or the appropriate Github repository permissions (community list).
kustomize-admins: # Please keep in sync with kustomize-admins in https://github.com/kubernetes/org/blob/main/config/kubernetes-sigs/sig-cli/teams.yaml
- monopole
- pwittrock
kustomize-maintainers: # Please keep in sync with kustomize-maintainers in https://github.com/kubernetes/org/blob/main/config/kubernetes-sigs/sig-cli/teams.yaml
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
