-
Notifications
You must be signed in to change notification settings - Fork 553
Add channel entries to the packagemanifests API #2893
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 channel entries to the packagemanifests API #2893
Conversation
Skipping CI for Draft Pull Request. |
e9c7323
to
f0ca220
Compare
@@ -512,6 +512,22 @@ func TestRegistryProviderGet(t *testing.T) { | |||
require.NoError(t, json.Unmarshal([]byte(etcdCSVJSON), &csv)) | |||
return operators.CreateCSVDescription(&csv, etcdCSVJSON) | |||
}(), | |||
Entries: []operators.ChannelEntry{ |
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.
Given that the entry list for test prometheus and etcd operators is reused throughout, does it make sense to declare them as objects which we can reuse?
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.
Done!
f0ca220
to
143acfa
Compare
@@ -81,6 +80,17 @@ type PackageChannel struct { | |||
|
|||
// CurrentCSVSpec holds the spec of the current CSV | |||
CurrentCSVDesc CSVDescription | |||
|
|||
// Entries lists all CSVs in the channel, with their upgrade edges. | |||
Entries []ChannelEntry |
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: would refactoring to Entries
to ChannelEntries
improve readability?
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 could go either way. We're already in the PackageChannel
struct, and none of the other fields have a Channel
prefix, so my instinct was just Entries
.
I did originally have the struct type ChannelEntry
called Entry
. I changed from Entry
to ChannelEntry
in that case because the type is defined at the package level, and it made sense to me for usage of the struct from outside the package to look like operators.ChannelEntry
rather than operators.Entry
/lgtm |
143acfa
to
3e8c8c3
Compare
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: grokspawn, joelanford 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 |
Signed-off-by: Joe Lanford <[email protected]>
3e8c8c3
to
0a89489
Compare
/lgtm |
Description of the change:
Add list of channel entries to the package manifest API, where each entry includes the CSV name and version.
Motivation for the change:
Surface list of available bundles, which can help users understand what can be installed (e.g. answer to queston: "what can i set startingCSV to?").
See also:
list-available
command does not show old versions of operators, only channel heads kubectl-operator#1Architectural changes:
None. Only notable change is that the package server calls
ListBundles
to get this information when syncing a catalog source.Testing remarks:
Reviewer Checklist
/doc
[FLAKE]
are truly flaky and have an issue