Differential Updates for Composable Components #1426
Comments
|
Once zarf packages can be composed from an OCI registry, could we reuse the image logic (which I believe only pulls if the hash is different) for packaging of OCI components? |
|
We released the first version of OCI support yesterday in v0.25.0-rc2 and will be working this next as a pre-requisite: #1060. Supporting OCI composability will make comparing and versioning differential updates easier in the future. |
|
Added a discussion here: #1438 |
|
Relates to #19 |
Racer159
added a commit
that referenced
this issue
May 4, 2023
Add a differential flag when building zarf packages so that packages can be created that are iterations of a prior package without needing to fully download any packages resources that have stayed the same since the last package build. Some discussion for this capability can be found here: #1438 #1426 TODO: - [x] Write a test - [x] find a better way to get the ref,tag,branch,etc from gitURLs when considering differential package contents --------- Co-authored-by: Wayne Starr <[email protected]>
|
#1650 delivered this partially but moving the OCI piece back to be delivered after OCI composability is actually released. |
Racer159
added a commit
that referenced
this issue
May 17, 2023
## Description
Allows for skeleton packages to be published and components imported via
OCI:
```bash
$ zarf package publish examples/helm-local-chart oci://localhost:555 --insecure
```
```yaml
- name: import-component-oci
required: false
import:
# name is optional, if not provided the name of the component will be used to import
name: demo-helm-local-chart
url: oci://localhost:555/helm-local-chart:0.0.1
actions:
onDeploy:
after:
- wait:
cluster:
kind: deployment
name: local-demo
namespace: local-chart
condition: available
```
This adds the following behavior to `zarf package publish`:
- `$version-skeleton`: If a directory is specified, the skeleton package
will be published (and can be used for composability)
- `$version-$arch`: If a tarball is specified, that fully rendered
package will be published
## Related Issue
Fixes #1097
Fixes #1060
Relates to #1426
Fixes #1560
Fixes #1215
## Type of change
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [x] Other (security config, docs update, etc)
## Checklist before merging
- [x] Test, docs, adr added or updated as needed
- [x] [Contributor Guide
Steps](https://github.com/defenseunicorns/zarf/blob/main/CONTRIBUTING.md#developer-workflow)
followed
---------
Signed-off-by: razzle <[email protected]>
Co-authored-by: Wayne Starr <[email protected]>
Co-authored-by: Jon Perry <[email protected]>
Co-authored-by: Wayne Starr <[email protected]>
Racer159
added a commit
that referenced
this issue
May 19, 2023
…1714) When creating a differential package, Zarf now considers OCI imported components as versioned assets. Since the OCI imported components are versioned assets, if Zarf is performing a differential build and the version of the OCI component we're important hasn't changed, Zarf will no longer include that OCI-Imported Component in the finalized differential Package. Closes #1426 --------- Co-authored-by: Wayne Starr <[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.
As a package creator using composable components, it is frustrating to rebuild / update large zarf packages that apply only small updates / incremental changes.
Describe the solution you'd like
I would like 'zarf package create` on a composed package to only rebuild the component packages that have changed. This would encourage smaller, more frequent updates more efficiently. Conversely, the current state of zarf may incentivize larger batch updates (which carry more risk) or decentralized zarf packages(requires documentation outside of the packages / introduces more opportunities for human error).
Describe alternatives you've considered
Planning long walks and engagements during package build pipelines, using decoupled / decentralized zarf packages, naps, or potentially looking at zarf actions to help build differential Updates smartly (introduces additional complexity and doesn't afford reusability for others).
The text was updated successfully, but these errors were encountered: