-
Notifications
You must be signed in to change notification settings - Fork 67
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
Add conditions as future replacement of requirements #519
Conversation
Throwing this in here as I found some additional conditions in an old file:
But these are probably more on the dataset level. |
@@ -10,6 +10,9 @@ release: ga | |||
|
|||
owner.github: "ruflin" | |||
|
|||
conditions: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ph @michalpristas I initially was thinking about aligning the syntax with the constraints on the agent. But it only complicates things. The reason is that the available conditions here are very limited and have very specific checks. Adding additional "non yaml" syntax only complicates things. So here is what I'm proposing at the moment.
As each condition
can only be used once I made it a key/value pair instead of an array.
One thing I think we should align is the naming. I landed on conditions as I think it fits best in all the places. WDYT about renaming it also in the agent?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 on using "conditions" instead of constraints, which would align with dynamic input.
Now, I am Okayish with using key values pair, for what you are proposing.
- Its a limited set of fixed conditions.
- The conditions are joined with an AND this mean all condition predicates must return true.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, using key/value also mean you don't have to have the parser in Kibana and we don't have to share code in the registry.
So since everything is defined upfront I do not see a concern if the syntax arent the same, it's easier to start fixed and limited than to be dynamic all the way.
Marked this as ready for review but it seems currently Github is flaky and has not picked up the most recent commits that I pushed :-( |
6f0f3dc
to
ad1bca1
Compare
As soon as elastic/package-registry#519 is merged, the mod file needs to be updated to the most recent version of the registry.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Requirements will be removed as soon as packages are updated.
It would be faster to introduce such changes once new integrations are already merged. Otherwise, we need to track if all PRs are correctly rebased.
@@ -31,6 +31,9 @@ | |||
"versions": "\u003e6.7.0" | |||
} | |||
}, | |||
"conditions": { | |||
"kibana.version": "\u003e6.7.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder why some fields are in such encoded format and some are not: kibana.version: ">6.7.0 <7.6.0"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The "problem" is the >
char which gets converted. But I tested this quite some time ago and it works as expected even though it is converted.
util/package.go
Outdated
@@ -97,6 +98,11 @@ type Requirement struct { | |||
Kibana ProductRequirement `config:"kibana" json:"kibana,omitempty" yaml:"kibana"` | |||
} | |||
|
|||
type Conditions struct { | |||
KibanaVersion string `config:"kibana.version,omitempty" json:"kibana.version,omitempty" yaml:"kibana.version,omitempty"` | |||
kibanaVersion *semver.Constraints |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest to rename this field, the difference is in capitals. How about kibanaConstraint
or kibanaSemver
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Renamed to kibanaConstraint
.
Is there any meta-issue to link this PR? |
This PR needs updating after elastic/package-registry#519 is merged.
Meta issue tracking this change is in #517 |
This change adds `conditions` as part of the package manifest to align with other parts in the stack. Currently it adds the future of conditions and does not remove requirements yet. Requirements will be removed as soon as packages are updated.
@mtojek PR updated with the reviews. Could you take a look again? |
As soon as elastic/package-registry#519 is merged, the mod file needs to be updated to the most recent version of the registry.
util/package.go
Outdated
if p.Conditions != nil && p.Conditions.KibanaVersion != "" { | ||
p.Conditions.kibanaConstraint, err = semver.NewConstraint(p.Conditions.KibanaVersion) | ||
if err != nil { | ||
return nil, errors.Wrapf(err, "invalid Kibana versions range: %s", p.Requirement.Kibana.Versions) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be p.Conditions.KibanaVersion
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
@@ -185,8 +191,18 @@ func NewPackage(basePath string) (*Package, error) { | |||
|
|||
p.Downloads = []Download{NewDownload(*p, "tar")} | |||
|
|||
if p.Requirement.Kibana.Versions != "" { | |||
p.Requirement.Kibana.semVerRange, err = semver.NewConstraint(p.Requirement.Kibana.Versions) | |||
// If the new conditions are used, select them over the requirements |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is duplicated code in this if-else to account for the new and legacy settings. Looks like the intent is to use the new setting, p.Conditions.KibanaVersion
. So why not do something like this instead?
p.setKibanaVersion()
if p.Conditions != nil && p.Conditions.KibanaVersion != "" {
...
}
func (p *Package) setKibanaVersion() {
if p.Conditions != nil && p.Conditions.KibanaVersion != "" {
return
}
if p.Requirement.Kibana.Versions != "" {
if p.Conditions == nil {
// initialize p.Conditions
}
p.Conditions.KibanaVersion = p.Requirement.Kibana.Versions
}
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ycombinator The legacy code should only be around for 24-48h, so I was sloppy.
@@ -40,6 +40,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 | |||
* Add list of downloads to /search endpoint. [#512](https://github.com/elastic/package-registry/pull/512) | |||
* Apply rule: first package found served. [#546](https://github.com/elastic/package-registry/pull/546) | |||
* Implement package watcher. [#553](https://github.com/elastic/package-registry/pull/553) | |||
* Add conditions as future replacement of requirements. [#519](https://github.com/elastic/package-registry/pull/519) | |||
|
|||
### Deprecated |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should requirements be deprecated?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will be removed in a few hours ;-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a note about the CHANGELOG. Code and test changes LGTM.
post merge LGTM? |
This change adds
conditions
as part of the package manifest to align with other parts in the stack. Currently it adds the future of conditions and does not remove requirements yet. Requirements will be removed as soon as packages are updated.