Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added validation if someone specifies a version on a bundle #3148

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

dgannon991
Copy link
Contributor

What does this change

Added a check on version numbers if specified in your porter YAML

What issue does it fix

Delivers towards #3136

Notes for the reviewer

This is just a draft to get some feedback. I intend to refactor the Lint() function and add some unit tests, but I wanted to check if I'd gone down the right route first :)

Signed-off-by: David Gannon <19214156+dgannon991@users.noreply.github.com>
@dgannon991 dgannon991 force-pushed the feat/3136/mixin-version-support branch from 2a2d8e8 to 4ebfb8e Compare June 4, 2024 08:01
Signed-off-by: David Gannon <19214156+dgannon991@users.noreply.github.com>
Signed-off-by: David Gannon <19214156+dgannon991@users.noreply.github.com>
Signed-off-by: David Gannon <19214156+dgannon991@users.noreply.github.com>
Signed-off-by: David Gannon <19214156+dgannon991@users.noreply.github.com>
@dgannon991 dgannon991 marked this pull request as ready for review June 5, 2024 14:40
@dgannon991
Copy link
Contributor Author

I've added some tests and done a small refactor on the bottom of Lint(). Let me know if we want to break further parts of the function out!

Signed-off-by: David Gannon <19214156+dgannon991@users.noreply.github.com>
func (l *Linter) validateVersionNumberConstraints(ctx context.Context, m *manifest.Manifest) error {
for _, mixin := range m.Mixins {
if mapConfig, ok := mixin.Config.(map[string]interface{}); ok {
if v, exists := mapConfig["version"]; exists {
Copy link
Contributor

Choose a reason for hiding this comment

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

Are there currently anything ensuring that mixins cannot use a config field called version?
I'm thinking of the situation where mixins already provide a field called version, which might result in unintended behaviour

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, it was simply the suggested field name on the issue. We could always use mixinVersion or something more verbose to avoid clashing?

Copy link
Contributor

Choose a reason for hiding this comment

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

I personally like version the best, but it could break some existing plugins.
@schristoff do you know of any way we can easily handle a "reservation" of a mixin configuration property?

Copy link

@KurtSchenk KurtSchenk Jun 13, 2024

Choose a reason for hiding this comment

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

@kichristensen, @schristoff could a similar approach such as porter-state, porter-debug be taken?
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging this pull request may close these issues.

None yet

3 participants