-
Notifications
You must be signed in to change notification settings - Fork 239
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
implement opm alpha render-veneer semver
#948
Conversation
opm alpha render-veneer semver
, prior art from https://github.com/joelan…opm alpha render-veneer semver
Codecov Report
@@ Coverage Diff @@
## master #948 +/- ##
==========================================
+ Coverage 52.48% 52.61% +0.12%
==========================================
Files 103 104 +1
Lines 9240 9422 +182
==========================================
+ Hits 4850 4957 +107
- Misses 3468 3535 +67
- Partials 922 930 +8
Continue to review full report at Codecov.
|
9e66aeb
to
aa860cd
Compare
aa860cd
to
eaa241a
Compare
Signed-off-by: Jordan Keister <jordan@nimblewidget.com>
c98281d
to
f1500b5
Compare
opm alpha render-veneer semver
opm alpha render-veneer semver
preview comments:
later review comments:
|
opm alpha render-veneer semver
opm alpha render-veneer semver
14c98db
to
063997d
Compare
this is true
but this isn't. we shouldn't include that replaces value if we're crossing over a major version number transition. So only minor version channels will have these channel cross-over replaces edges. |
No, there should only be edges that connect to actual bundles listed in the veneer. If the veneer contains some v1.1 bundles, but no v1.0 bundles, then the leaf nodes of that v1.1 channels will all be skips and there will be no replace to a previous v1.0 bundle (because there isn't one). |
93bf7e8
to
26f502b
Compare
26f502b
to
3962fc8
Compare
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.
This looks good to me, no major functional changes requested. Great work!
cfd56bb
to
6569f5d
Compare
/lgtm |
Signed-off-by: Jordan Keister <jordan@nimblewidget.com> Signed-off-by: Ankita Thomas <ankithom@redhat.com>
6569f5d
to
6ff7571
Compare
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.
/lgtm
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.
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ankitathomas, awgreene, dinhxuanvu, grokspawn The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
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.
Had some left-over comments after this got merged. Not blocking at all so we can address later if we feel the need.
/lgtm
// IO structs -- BEGIN | ||
type semverVeneerBundleEntry struct { | ||
Image string `json:"image,omitempty"` | ||
} | ||
|
||
type candidateBundles struct { | ||
Bundles []semverVeneerBundleEntry `json:"bundles,omitempty"` | ||
} | ||
type fastBundles struct { | ||
Bundles []semverVeneerBundleEntry `json:"bundles,omitempty"` | ||
} | ||
type stableBundles struct { | ||
Bundles []semverVeneerBundleEntry `json:"bundles,omitempty"` | ||
} | ||
|
||
type semverVeneer struct { | ||
Schema string `json:"schema"` | ||
GenerateMajorChannels bool `json:"generateMajorChannels,omitempty"` | ||
GenerateMinorChannels bool `json:"generateMinorChannels,omitempty"` | ||
AvoidSkipPatch bool `json:"avoidSkipPatch,omitempty"` | ||
Candidate candidateBundles `json:"candidate,omitempty"` | ||
Fast fastBundles `json:"fast,omitempty"` | ||
Stable stableBundles `json:"stable,omitempty"` | ||
|
||
pkg string `json:"-"` // the derived package name | ||
defaultChannel string `json:"-"` // detected "most stable" channel head | ||
} | ||
|
||
// IO structs -- END |
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.
nit: I'd personally like to see an individual comment describing each of these struct but understand that may not be a shared opinion. My thought here is that it makes it easier for maintainers to come through later and understand how these structs are used faster.
|
||
// channel "kinds", restricted in this iteration to just these | ||
const ( | ||
candidateChannelName string = "candidate" |
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.
Can definitely be followed-up since this is an alpha command, but it is relatively trivial to add configurable channels for this so we have both these defaults and consumer-defined ones. Have thought about making a flag that we iterate over for these in a follow-up? The flag type can even be of type map[string]int
like you define on line 64 making these feel pretty natural.
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 goal of this particular veneer was to focus on and encourage the candidate < fast < stable channel set as a MVP which endorses/encourages our internal practice. "Guidelines and guardrails" is how I like to refer to it.
It wouldn't be hard, but it was counter to our goals at this stage.
We can iterate into a variant or leave it as an exercise for the operator author who needs it. Early feedback will help guide us.
NOTE: Updated comments/docs from yesterday's peer review.
Signed-off-by: Jordan Keister jordan@nimblewidget.com
Description of the change:
Implements a "SemVer"
Veneer
rendering capability, to illustrate the potential benefits of the use ofveneer
as entry points into the FBC ecosystem.Since a
veneer
is identified as an input schema which may be processed to generate a valid FBC, we can define asemver veneer
as a schema which uses channel conventions to facilitate the auto-generation of channels alongsemver
delimiters.Please see the README.md for complete description.
Motivation for the change:
Illustrate a possible effort-saving work flow for operator authors to use to facilitate migration to
FBC
.Reviewer Checklist
/docs