feat: new major 2.0 release

.github/workflows/_check_deno_lock_upstream.yml

@@ -0,0 +1,44 @@
+name: xxxxx(internal)
+
+on:
+  workflow_call:
+    inputs:
+      forceSkip:
+        default: false
+        type: string
+
+defaults:
+  run:
+    shell: bash
+
+env:
+  DEBIAN_FRONTEND: "noninteractive"
+
+jobs:
+  _:
+    if: inputs.forceSkip == 'false'
+    runs-on: ubuntu-22.04
+    timeout-minutes: 10
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v6
+
+      - name: Set up Go
+        uses: actions/setup-go@v6
+        with:
+          cache: false
+          go-version-file: go.mod
+
+      - name: Install Task
+        uses: go-task/setup-task@v2
+        with:
+          repo-token: ${{ secrets.GITHUB_TOKEN }}
+
+      # Fails when the release assets the lock pins no longer hash to what it records: GitHub lets an
+      # asset be replaced without moving its tag, and nothing else would notice, since builds verify
+      # against the committed lock and never look upstream. A newer Deno release is only reported,
+      # since bumping the pin is a decision.
+      - name: Check the pinned Deno release against upstream
+        run: task -p check:deno-lock-upstream
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

.github/workflows/_check_validation_schemas_upstream.yml

@@ -0,0 +1,43 @@
+name: xxxxx(internal)
+
+on:
+  workflow_call:
+    inputs:
+      forceSkip:
+        default: false
+        type: string
+
+defaults:
+  run:
+    shell: bash
+
+env:
+  DEBIAN_FRONTEND: "noninteractive"
+
+jobs:
+  _:
+    if: inputs.forceSkip == 'false'
+    runs-on: ubuntu-22.04
+    timeout-minutes: 10
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v6
+
+      - name: Set up Go
+        uses: actions/setup-go@v6
+        with:
+          cache: false
+          go-version-file: go.mod
+
+      - name: Install Task
+        uses: go-task/setup-task@v2
+        with:
+          repo-token: ${{ secrets.GITHUB_TOKEN }}
+
+      # Fails when upstream changed schemas the committed archives were generated from, which is the
+      # only signal that "task generate:validation-schemas:force" is due: the generator itself never
+      # goes looking, so that builds stay offline and reproducible.
+      - name: Check embedded validation schemas against upstream
+        run: task -p check:validation-schemas-upstream
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

.github/workflows/test_daily.yml

@@ -11,6 +11,12 @@ jobs:
   lint:
     uses: ./.github/workflows/_lint.yml
 
+  check_validation_schemas_upstream:
+    uses: ./.github/workflows/_check_validation_schemas_upstream.yml
+
+  check_deno_lock_upstream:
+    uses: ./.github/workflows/_check_deno_lock_upstream.yml
+
   unit:
     uses: ./.github/workflows/_test_unit.yml
     with:
@@ -26,6 +32,8 @@ jobs:
     if: always()
     needs:
       - lint
+      - check_validation_schemas_upstream
+      - check_deno_lock_upstream
       - coverage_report
     uses: werf/common-ci/.github/workflows/notification.yml@main
     secrets:

.github/workflows/test_pr.yml

@@ -35,6 +35,7 @@ jobs:
               - 'go.mod'
               - 'go.sum'
               - 'cmd/nelm/**'
+              - 'internal/**'
               - 'pkg/**'
               - 'scripts/**'
             lint:

.gitignore

@@ -1,5 +1,6 @@
 *.swp
 *.test
+.task
 /.idea/
 /.vscode/
 /Taskfile.yaml
@@ -9,5 +10,10 @@
 /go.work
 /go.work.sum
 node_modules/
+/pkg/ts/embed/*/*/deno.gz
+/pkg/ts/embed/*/*/deno.gz.*.tmp
 /.opencode/
 /.sisyphus
+
+# Regenerated by TestDependencyBuildCmdWithHelmV2Hash on every run (fresh mtimes)
+/pkg/helm/pkg/cmd/testdata/testcharts/issue-7233/charts/alpine-0.1.0.tgz

AGENTS.md

@@ -2,7 +2,7 @@
 
 All rules in this document are requirements — not suggestions. ALWAYS follow them.
 
-Nelm is a Go-based Kubernetes deployment tool, which deploys Helm charts, is compatible with Helm releases, and is an alternative to Helm. Nelm also used as the deployment engine of [werf](https://github.com/werf/werf).
+Nelm is a Go-based Kubernetes deployment tool, which deploys Helm charts, is compatible with Helm releases, and is an alternative to Helm. Nelm is built on top of a Helm fork and is also used as the deployment engine of [werf](https://github.com/werf/werf).
 
 ## Highest-priority rule (MANDATORY)
 
@@ -75,7 +75,7 @@ ALWAYS use these `task` commands. NEVER use raw `go build`, `go test`, `go fmt`,
 - ALWAYS place tests alongside source files, not in a separate directory.
 - Test helpers go in `helpers_test.go` (or `helpers_ai_test.go` for AI-written helpers).
 - Test fixtures go in `testdata/` subdirectory next to the tests.
-- Shared test helpers are in `internal/test/`.
+- Shared test helpers are in `pkg/test/`.
 
 ## PR review guidelines (MANDATORY)
 
@@ -85,6 +85,6 @@ ALWAYS use these `task` commands. NEVER use raw `go build`, `go test`, `go fmt`,
 
 ## Related repositories
 
-- [werf/kubedog](https://github.com/werf/kubedog) — Kubernetes resource tracking library. Used by `internal/track/`.
+- [werf/kubedog](https://github.com/werf/kubedog) — Kubernetes resource tracking library. Used by `pkg/track/`.
 - [werf/common-go](https://github.com/werf/common-go) — Shared Go libraries (secrets, CLI utilities, locking).
 - [werf/werf](https://github.com/werf/werf) — CI/CD tool that uses nelm as its deployment engine.

CLAUDE.md

@@ -0,0 +1 @@
+AGENTS.md

README.md

@@ -54,8 +54,6 @@ Nelm is production-ready: as the werf deployment engine, it was battle-tested ac
   - [`werf.io/weight` annotation](#werfioweight-annotation)
   - [`werf.io/deploy-dependency-<id>` annotation](#werfiodeploy-dependency-id-annotation)
   - [`werf.io/delete-dependency-<id>` annotation](#werfiodelete-dependency-id-annotation)
-  - [`<id>.external-dependency.werf.io/resource` annotation](#idexternal-dependencywerfioresource-annotation)
-  - [`<id>.external-dependency.werf.io/name` annotation](#idexternal-dependencywerfioname-annotation)
   - [`werf.io/ownership` annotation](#werfioownership-annotation)
   - [`werf.io/deploy-on` annotation](#werfiodeploy-on-annotation)
   - [`werf.io/delete-policy` annotation](#werfiodelete-policy-annotation)
@@ -87,7 +85,6 @@ Nelm is production-ready: as the werf deployment engine, it was battle-tested ac
   - [`NELM_FEAT_NATIVE_RELEASE_UNINSTALL` environment variable](#nelm_feat_native_release_uninstall-environment-variable)
   - [`NELM_FEAT_PERIODIC_STACK_TRACES` environment variable](#nelm_feat_periodic_stack_traces-environment-variable)
   - [`NELM_FEAT_FIELD_SENSITIVE` environment variable](#nelm_feat_field_sensitive-environment-variable)
-  - [`NELM_FEAT_CLEAN_NULL_FIELDS` environment variable](#nelm_feat_clean_null_fields-environment-variable)
   - [`NELM_FEAT_MORE_DETAILED_EXIT_CODE_FOR_PLAN` environment variable](#nelm_feat_more_detailed_exit_code_for_plan-environment-variable)
 - [More documentation](#more-documentation)
 - [Limitations](#limitations)
@@ -182,11 +179,11 @@ Dependency commands:
   chart dependency update            Update Chart.lock and download chart dependencies.
 
 Repo commands:
-  repo add                           Set up a new chart repository.
-  repo remove                        Remove a chart repository.
-  repo update                        Update info about available charts for all chart repositories.
-  repo login                         Log in to an OCI registry with charts.
-  repo logout                        Log out from an OCI registry with charts.
+  chart repo add                     Set up a new chart repository.
+  chart repo remove                  Remove a chart repository.
+  chart repo update                  Update info about available charts for all chart repositories.
+  chart repo login                   Log in to an OCI registry with charts.
+  chart repo logout                  Log out from an OCI registry with charts.
 
 Other commands:
   completion bash                    Generate the autocompletion script for bash
@@ -223,8 +220,8 @@ Generally, the migration from Helm to Nelm should be as simple as changing Helm
 
 The resource deployment subsystem of Helm is rewritten from scratch in Nelm. During the deployment, Nelm builds the Directed Acyclic Graph (DAG) of all operations we want to perform in the cluster to do the release, then the DAG is executed. The DAG allowed us to implement advanced resource ordering capabilities, such as:
 * The `werf.io/weight` annotation: similar to `helm.sh/hook-weight`, but also works for non-hook resources. Resources with the same weight deployed in parallel.
-* The `werf.io/deploy-dependency-<id>` annotation: do not deploy the annotated resource until the dependency is present or ready. This is the most powerful and effective way to enforce deployment order in Nelm.
-* The `<id>.external-dependency.werf.io/resource` annotation: do not deploy the annotated resource until the dependency is ready. The dependency can be an external, non-release resource, e.g. a resource created by a third-party operator.
+* The `werf.io/deploy-dependency-<id>` annotation: do not deploy the annotated resource until the dependency is present or ready. Works for both release resources and external cluster resources (e.g. resources created by a third-party operator). This is the most powerful and effective way to enforce deployment order in Nelm.
+* The `werf.io/delete-dependency-<id>` annotation: do not delete the annotated resource until the dependency is absent. Works for both release resources and external cluster resources.
 * Helm Hooks and their weights are supported, too.
 
 ![ordering](resources/images/graph.png)
@@ -373,58 +370,39 @@ Default:
 
 ### `werf.io/deploy-dependency-<id>` annotation 
 
-The resource will deploy only after all of its dependencies are satisfied. It waits until the specified resource is just `present` or is also `ready`. It serves as a more powerful alternative to hooks and `werf.io/weight`. You can only point to resources in the release. This annotation has higher priority than `werf.io/weight` and `helm.sh/hook-weight`. This annotation has no effect if the resource on which we depend upon is outside the stage (pre, main, post, ...) of the resource with the annotation.
+The resource will deploy only after all of its dependencies are satisfied. It waits until the specified resource is just `present` or is also `ready`. It serves as a more powerful alternative to hooks and `werf.io/weight`. This annotation has higher priority than `werf.io/weight` and `helm.sh/hook-weight`. This annotation has no effect on internal (release) dependencies if the resource on which we depend upon is outside the stage (pre, main, post, ...) of the resource with the annotation.
+
+If `external=true` or `external=auto` and the dependency is not found in the release, then the dependency is treated as external to the release: `name`, `kind` and `version` must be specified.
 
 Example:
 ```yaml
 werf.io/deploy-dependency-db: state=ready,kind=StatefulSet,name=postgres
 werf.io/deploy-dependency-app: state=present,kind=Deployment,group=apps,version=v1,name=app,namespace=app
+werf.io/deploy-dependency-secret: state=ready,kind=Secret,version=v1,name=my-vault-secret,external=true
 ```
 Format:
 ```
-werf.io/deploy-dependency-<anything>: state=ready|present[,name=<name>][,namespace=<namespace>][,kind=<kind>][,group=<group>][,version=<version>]
+werf.io/deploy-dependency-<anything>: state=ready|present[,name=<name>][,namespace=<namespace>][,kind=<kind>][,group=<group>][,version=<version>][,external=auto|true|false]
 ```
 
 ### `werf.io/delete-dependency-<id>` annotation
 
-The resource will be deleted only after all of its dependencies are satisfied. It waits until the specified resource is `absent`. You can only point to resources in the release. This annotation has no effect if the resource on which we depend upon is outside the stage (pre, main, post, ...) of the resource with the annotation.
+The resource will be deleted only after all of its dependencies are satisfied. It waits until the specified resource is `absent`. This annotation has no effect on internal (release) dependencies if the resource on which we depend upon is outside the stage (pre, main, post, ...) of the resource with the annotation.
+
+If `external=true` or `external=auto` and the dependency is not found in the release, then the dependency is treated as external to the release: `name`, `kind` and `version` must be specified.
 
 Example:
 ```yaml
 werf.io/delete-dependency-db: state=absent,kind=StatefulSet,name=postgres
 werf.io/delete-dependency-app: state=absent,kind=Deployment,group=apps,version=v1,name=app,namespace=app
+werf.io/delete-dependency-secret: state=absent,kind=Secret,version=v1,name=my-vault-secret,external=true
 ```
 Format:
 ```
-werf.io/delete-dependency-<anything>: state=absent[,name=<name>][,namespace=<namespace>][,kind=<kind>][,group=<group>][,version=<version>]
-```
-
-### `<id>.external-dependency.werf.io/resource` annotation 
-
-The resource will deploy only after all of its external dependencies are satisfied. It waits until the specified resource is `present` and `ready`. You can only point to resources outside the release.
-
-Example:
-```yaml
-secret.external-dependency.werf.io/resource: secret/config
-someapp.external-dependency.werf.io/resource: deployments.v1.apps/app
-```
-Format:
-```
-<anything>.external-dependency.werf.io/resource: <kind>[.<version>.<group>]/<name>
+werf.io/delete-dependency-<anything>: state=absent[,name=<name>][,namespace=<namespace>][,kind=<kind>][,group=<group>][,version=<version>][,external=auto|true|false]
 ```
 
-### `<id>.external-dependency.werf.io/name` annotation 
 
-Set the namespace of the external dependency defined by `<id>.external-dependency.werf.io/resource`. `<id>` must match on both annotations. If not specified, the release namespace is used.
-
-Example:
-```yaml
-someapp.external-dependency.werf.io/name: someapp-production
-```
-Format:
-```
-<anything>.external-dependency.werf.io/name: <name>
-```
 
 ### `werf.io/ownership` annotation 
 
@@ -866,18 +844,6 @@ export NELM_FEAT_FIELD_SENSITIVE=true
 nelm release plan install -n myproject -r myproject
 ```
 
-### `NELM_FEAT_CLEAN_NULL_FIELDS` environment variable
-
-Improve Helm chart compatibility. When rendering charts, remove keys with `null` values from the rendered resource manifests, before applying them. Otherwise, SSA often fail on `null` values, which didn't happen with 3WM.
-
-Will be the default in the next major release.
-
-Example:
-```shell
-export NELM_FEAT_CLEAN_NULL_FIELDS=true
-nelm release install -n myproject -r myproject
-```
-
 ### `NELM_FEAT_MORE_DETAILED_EXIT_CODE_FOR_PLAN` environment variable
 
 When the `--exit-code` flag is specified for `nelm release plan install`, return exit code 3, if no resource changes planned, but release still must be installed. Previously, exit code 2 was returned in this case.