Skip to content

feat(schema): update v1beta1 types#4704

Open
AustinAbro321 wants to merge 30 commits into
mainfrom
update-v1beta1-schema
Open

feat(schema): update v1beta1 types#4704
AustinAbro321 wants to merge 30 commits into
mainfrom
update-v1beta1-schema

Conversation

@AustinAbro321

Copy link
Copy Markdown
Member

Description

This brings the v1beta1 schema in line with what is proposed in zarf-dev/proposals#52

Relates to #3433

Checklist before merging

Signed-off-by: Austin Abro <austinabro321@gmail.com>
Signed-off-by: Austin Abro <austinabro321@gmail.com>
Signed-off-by: Austin Abro <austinabro321@gmail.com>
Signed-off-by: Austin Abro <austinabro321@gmail.com>
@netlify

netlify Bot commented Mar 11, 2026

Copy link
Copy Markdown

Deploy Preview for zarf-docs canceled.

Name Link
🔨 Latest commit ce2f4a4
🔍 Latest deploy log https://app.netlify.com/projects/zarf-docs/deploys/6a21b2db2bac620008a00d76

@codecov

codecov Bot commented Mar 11, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 44.68085% with 26 lines in your changes missing coverage. Please review.

Files with missing lines Patch % Lines
src/api/v1beta1/component.go 42.85% 12 Missing ⚠️
src/api/v1beta1/package.go 54.54% 10 Missing ⚠️
src/api/v1alpha1/package.go 0.00% 4 Missing ⚠️
Files with missing lines Coverage Δ
src/api/v1alpha1/package.go 85.00% <0.00%> (-9.45%) ⬇️
src/api/v1beta1/package.go 54.54% <54.54%> (ø)
src/api/v1beta1/component.go 42.85% <42.85%> (ø)

... and 9 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

AustinAbro321 and others added 18 commits March 11, 2026 15:41
Signed-off-by: Austin Abro <austinabro321@gmail.com>
Signed-off-by: Austin Abro <austinabro321@gmail.com>
Signed-off-by: Austin Abro <austinabro321@gmail.com>
Signed-off-by: Austin Abro <austinabro321@gmail.com>
Signed-off-by: Austin Abro <austinabro321@gmail.com>
Signed-off-by: Austin Abro <austinabro321@gmail.com>
Signed-off-by: Austin Abro <austinabro321@gmail.com>
Signed-off-by: Austin Abro <austinabro321@gmail.com>
Signed-off-by: Austin Abro <austinabro321@gmail.com>
Signed-off-by: Austin Abro <austinabro321@gmail.com>
Signed-off-by: Austin Abro <austinabro321@gmail.com>
Signed-off-by: Austin Abro <austinabro321@gmail.com>
Signed-off-by: Austin Abro <austinabro321@gmail.com>
Signed-off-by: Austin Abro <austinabro321@gmail.com>
@AustinAbro321 AustinAbro321 marked this pull request as ready for review June 1, 2026 13:28
@AustinAbro321 AustinAbro321 requested review from a team as code owners June 1, 2026 13:28
@AustinAbro321 AustinAbro321 changed the title feat(schema): update v1beta1 schema feat(schema): update v1beta1 types Jun 1, 2026

@soltysh soltysh left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some high-level comments, but I'll do another pass regarding the API as a whole.

fmt.Println(err.Error())
os.Exit(1)
}
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any particular reason for generating two files for v1beta1? I think from a user perspective, it's easier to import a single file containing all the elements of the schema, rather than multiple.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are two files for the two different kinds. One is for the component config kind, while the other is for the package kind. To your point, perhaps we should call one of the package schema and one the component schema

Comment thread src/api/v1beta1/component.go Outdated
Comment thread src/api/v1beta1/component.go Outdated
}

// GetDeprecatedDataInjections returns the v1alpha1 data injections carried as a backwards-compatibility shim.
func (c Component) GetDeprecatedDataInjections() []v1alpha1.ZarfDataInjection {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know what you're trying to achieve, but I don't think this is the right way to do it. Currently, you're hiding the field as private, but you're providing public method for setting/getting it. This might mean, external consumers will be able to change it, and that's not what we want. This field should only be settable by our conversion logic, right?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment applies to all private fields here and in other files below.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed the setter, I believe we'll be able to use a different strategy in #4823 that we discussed

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#4823 is in draft, but I'm happy with the strategy there. It exposes a function SetDeprecatedFromGeneric(g types.Package, pkg Package) Package but it's only callable from Zarf since types.Package is internal

}

// GetImages returns all image names specified in the component, including those from ImageArchives.
func (c Component) GetImages() []string {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder about these struct methods vs just regular helpers, I don't have any strong preferences, but I like having clean API types only 😅

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the ergonomics of pulling data directly from the type, but I see where you're coming from

Comment thread src/api/v1beta1/component_config.go
Comment thread src/api/v1beta1/package.go Outdated
// ServerSideApplyDisabled always uses client-side apply.
ServerSideApplyDisabled ServerSideApplyMode = "false"
// ServerSideApplyAuto uses server-side apply for fresh installs and matches the prior strategy on upgrade.
ServerSideApplyAuto ServerSideApplyMode = "auto"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion, the above values, especially true and false might cause problems during yaml conversions. Should we consider turning all constants into upper cases values? Here, I'd specifically use Enabled, Disabled and Auto (alternatively Always, Never and Auto).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly, above we'd use Registry, SeedRegistry, Injector, etc.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since they will be in quotes it should be fine, we haven't run into any issues yet, and this is an existing field in the v1alpha1 schema. I want to keep it as "true", "false", "auto" since this is essentially a pass through of the options on the "helm install --server-side` flag.

Comment thread src/api/v1beta1/component.go Outdated
// Default timeout in seconds for commands (default 0, no timeout).
MaxTotalSeconds int32 `json:"maxTotalSeconds,omitempty"`
// Retry commands a given number of times if they fail (default 0).
Retries int32 `json:"retries,omitempty"`

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think, for both of these fields, I'm inclined to drop the omitempty, such that those will always show up in the yaml after zarf will process these. This will ensure users have those values explicit, especially when we default them to 0.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would disagree there, since removing omitempty will make it so the fields are required by our jsonschema when .actions.defaults is defined

// The timestamp when this package was created.
Timestamp string `json:"timestamp"`
// The version of Zarf used to build this package.
Version string `json:"version"`

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since BuildData field is omitempty inside Package, so there are some edge-cases when these values might show up as "", when at least one of the other fields is set.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this is okay. Zarf populates these fields, and we treat omitEmpty as a way to say these fields are "required" and Zarf will always populate them out when creating a package.

AustinAbro321 and others added 7 commits June 2, 2026 12:07
Signed-off-by: Austin Abro <austinabro321@gmail.com>
Signed-off-by: Austin Abro <austinabro321@gmail.com>
Signed-off-by: Austin Abro <austinabro321@gmail.com>
Signed-off-by: Austin Abro <austinabro321@gmail.com>
Signed-off-by: Austin Abro <austinabro321@gmail.com>
Signed-off-by: Austin Abro <austinabro321@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

3 participants