Skip to content

v0.22.0

Latest

Choose a tag to compare

@arnarg arnarg released this 19 Jun 15:06

Inspect your resource types right from the CLI - #12

Ever wished you had kubectl api-resources and kubectl explain, but for the resource types your nixidy environment actually knows about? Now you do. Meet nixidy resources:

# List every resource type registered for the environment.
>> nixidy resources .#prod
RESOURCE                            VERSION     GROUP                            KIND
mutatingWebhookConfigurations       v1          admissionregistration.k8s.io     MutatingWebhookConfiguration
validatingWebhookConfigurations     v1          admissionregistration.k8s.io     ValidatingWebhookConfiguration
customResourceDefinitions           v1          apiextensions.k8s.io             CustomResourceDefinition
# ...

And it drills right down into nested options, CRD-generated ones included:

>> nixidy resources .#prod ciliumNetworkPolicies.spec.endpointSelector
ciliumNetworkPolicies.spec.endpointSelector <null or (submodule)>

DESCRIPTION:
    EndpointSelector selects all endpoints which should be subject to
    this rule. EndpointSelector and NodeSelector cannot be both empty and
    are mutually exclusive.

FIELDS:
  matchExpressions  <null or (list of (submodule))>
    matchExpressions is a list of label selector requirements. The requirements are ANDed.

  matchLabels  <null or (attribute set of (string))>
    matchLabels is a map of {key,value} pairs...

Works with both the Nix/flake and devenv build backends. No more guessing what attrName a CRD landed under!

Keep your locally-defined charts up to date - #2 #77

If you've been vendoring charts with mkChartAttrs, keeping their versions and hashes fresh was a manual chore. Well, no more! Each chart now carries an updateScript in its passthru, and the new mkChartsUpdateScript wraps your whole chart tree into one runnable updater. Expose it as a flake app:

{
  outputs = { self, nixpkgs, flake-utils, nixidy, ... }:
    flake-utils.lib.eachDefaultSystem (system:
      let
        pkgs = import nixpkgs { inherit system; };
        inherit (pkgs) lib;
      in {
        apps.updateCharts = {
          type = "app";
          program = lib.getExe (nixidy.packages.${system}.mkChartsUpdateScript
            (nixidy.packages.${system}.mkChartAttrs ./charts));
        };
      });
}

And then run:

nix run .#updateCharts

It walks every chart, resolves the latest upstream version, recomputes the hash, and rewrites each default.nix in place.

Want to keep a chart version constrained? Two optional fields in a chart's default.nix have you covered:

  • versionConstraint: a semver range (e.g. ">=4.7.0 <5.0.0", "4.7.x") passed to helm show chart --version, so the updater sticks to the latest matching release rather than jumping majors on you.
  • freeze: set to true and the updater skips that chart entirely, for the ones you want pinned by hand.

See the new Updating Charts docs.

Improvements

  • Generators, neatly split in two. The pkgs/generators package was reorganized into a sources/ half (acquiring k8s sources, CRDs and chart CRDs) and a compile/ half (turning schemas into option modules), with default.nix reduced to just the wiring between them. No behavior change, just a tidier house. @sini #103
  • One source of truth for object intake & filenames. A trio of duplicated concerns across the application modules now each live in a single place, so they can't drift out of sync: the GVK-based resources/objects split (partitionObjects), the <Kind>-<dashed-name> filename stem (objectBaseName), and the nixidy.k8sVersion enum (now derived from the generated modules actually on disk). @sini #101