Continuous Delivery for connected environments #892
Labels
enhancement ✨
New feature or request
Comments
Merged
jeff-mccoy
added a commit
that referenced
this issue
Nov 30, 2022
This PR is a major refactor of the zarf code base primarily designed around better structure to support the current Zarf API as well as expose some key portions of Zarf as an SDK for other tools to consume. This major refactor came out of growing API needs as well as needs in #892 and the [zarf-controller](https://github.com/defenseunicorns/zarf-controller) prototype. Major changes: - Migrate all global configs used by the packager into [receiver methods](https://medium.com/globant/go-method-receiver-pointer-vs-value-ffc5ab7acdb) to avoid concurrency issues - Migrate from heavy `fatal` use to conventional error bubbling / wrapping - Expose core packager code as `github.com/defenseunicorns/zarf/src/pkg/packager` - Split the k8s package into `github.com/defenseunicorns/zarf/src/pkg/k8s` (external) and `src/internal/cluster` (internal) - Expose `message`, `pki`, and `utils` as `github.com/defenseunicorns/zarf/src/pkg/*` - Move the remaining `src/internal/*` packages (except for `agent` & `api`) into `src/internal/packager/*` - Change K8s connections to a reusable connection, except for `cluster.Tunnel` - Switch to Revive for linting - Introduce language file and establish basic patterns, related to #631 - Add SPDX headers to all files - Begin work to standardize on the [Uber Go Style Guide](https://github.com/uber-go/guide/blob/master/style.md) - Address a lot of lint issues - Return confirm yaml display to only show populated values Co-authored-by: Jon Perry <[email protected]> Co-authored-by: Wayne Starr <[email protected]>
Noxsios
pushed a commit
that referenced
this issue
Mar 8, 2023
This PR is a major refactor of the zarf code base primarily designed around better structure to support the current Zarf API as well as expose some key portions of Zarf as an SDK for other tools to consume. This major refactor came out of growing API needs as well as needs in #892 and the [zarf-controller](https://github.com/defenseunicorns/zarf-controller) prototype. Major changes: - Migrate all global configs used by the packager into [receiver methods](https://medium.com/globant/go-method-receiver-pointer-vs-value-ffc5ab7acdb) to avoid concurrency issues - Migrate from heavy `fatal` use to conventional error bubbling / wrapping - Expose core packager code as `github.com/defenseunicorns/zarf/src/pkg/packager` - Split the k8s package into `github.com/defenseunicorns/zarf/src/pkg/k8s` (external) and `src/internal/cluster` (internal) - Expose `message`, `pki`, and `utils` as `github.com/defenseunicorns/zarf/src/pkg/*` - Move the remaining `src/internal/*` packages (except for `agent` & `api`) into `src/internal/packager/*` - Change K8s connections to a reusable connection, except for `cluster.Tunnel` - Switch to Revive for linting - Introduce language file and establish basic patterns, related to #631 - Add SPDX headers to all files - Begin work to standardize on the [Uber Go Style Guide](https://github.com/uber-go/guide/blob/master/style.md) - Address a lot of lint issues - Return confirm yaml display to only show populated values Co-authored-by: Jon Perry <[email protected]> Co-authored-by: Wayne Starr <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
In connected environments where git repositories and OCI registries are touch-able by a target cluster, there is no automated way to deploy new updates to the cluster without manual
zarf package deploycommands being executed on the command line.Describe the solution you'd like
I would like to see an automated agent that watches upstream sources of artifacts (git repositories with Zarf.yaml files and OCI registries) that apply updates to the cluster based on changes in those artifacts.
In this initial POC I'd like to wrap Zarf in a controller that leverages the Fluxv2 ecosystem in the same way this Terraform Controller uses the source controller from Flux.
This controller could also host the Zarf UI in cluster for platform engineers to use to visualize what's been deployed in their environment
On Startup
the controller would perform a zarf init to the cluster
Watching GitRepository:
Zarf would perform a
zarf package createand azarf package deployWatching an OCIRepository
Zarf would perform a
zarf package deploy sget://<oci thingy>Describe alternatives you've considered
Buidling a controller that handles the functionality of the source controller from flux and this proposed Zarf controller
Additional context
Will update with diagrams/CRD ideas as they get fleshed out
The text was updated successfully, but these errors were encountered: