-
Notifications
You must be signed in to change notification settings - Fork 266
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
App upgrade notification shown for incorrect app (corrected filters and added further tests) #10180
Conversation
313d3a8
to
4496e57
Compare
… add covering tests
Also I noticed that we had already a talk about tests for Kubewarden here: |
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.
@jordojordo Can you validate kube warden side is fine? In the description Giuseppe mentions some kubewarden strageness
version: string, | ||
} | ||
|
||
export interface IChart { |
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 chart in our store represented by this interlaces comes from https://github.com/rancher/dashboard/blob/master/shell/store/catalog.js#L505. Via comment i think this should reference that, and vice versa
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 am aware of the JS file which I'm not going to touch 😄
What are you suggesting about the interface? I did not get it.
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 would just be to link the two together. So if someone updates the object they also know to update the interface, or want to know where the object is instantiated.
/*
* ...
* Created in `addChart` shell/store/catalog.js
*/
export interface IChart
// Instance of `IChart`
obj = classify(ctx, {
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.
Oh but I have absolutely no idea what do we have there, so I have just put what I know and then later someone will have to update just as I did, otherwise nobody would ever write anything, no?
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.
That's fine, but can you still add the suggested comments?
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.
yeah absolutely, just taking time :)
@@ -0,0 +1,30 @@ | |||
export interface IChartVersions { |
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 object this interface represents in from the entries
collection from catalog.cattle.io.clusterrepos
.
I think this should be called something like IClusterRepoChart
The object IChart
if for is constructed locally (https://github.com/rancher/dashboard/blob/master/shell/store/catalog.js#L505.). Suggest this one is called IDashboardChart
.
That makes it cleared what each one is.
chartNameDisplay: string; | ||
} | ||
|
||
export interface IChartOptions { |
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.
Suggest this one be renamed to something like 'IFilterChartOptions` to differentiate it from other options to do with charts
const newestChart = versions?.[0]; | ||
const newestVersion = newestChart?.version; | ||
|
||
if ( !thisVersion || !newestVersion ) { |
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 check, for truthy currentChartVersion and newestVersion, has been lost. i noticed that compare
now has
if (in1 === undefined && in2 === undefined) {
return null;
}
if that was meant for a replacement, would vote to keep compare
untouched and to bring it back to this context (as compare is used in other places). So it would be
if (!currentChartVersion || !newestVersion) {
return null;
}
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.
It fails if I keep as it is, I'll try to check what I can do.
Ideally would be convenient to have real data to understand better the suggestion.
const newestChart = versions?.[0]; | ||
const newestVersion = newestChart?.version; | ||
|
||
if ( !thisVersion || !newestVersion ) { |
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.
Apart from the check for undefined above, the other changes in upgradeAvailable are just tidying up? just want to be sure i haven't missed something
@@ -40,69 +41,48 @@ export default class CatalogApp extends SteveModel { | |||
} | |||
|
|||
matchingChart(includeHidden) { | |||
const chart = this.spec?.chart; | |||
|
|||
if ( !chart ) { |
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 early exit has been lost
}); | ||
|
||
describe('as latest version', () => { | ||
it('excluding pre-releases', () => { |
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 title of this test is wrong, it returns the success case where there is an upgrade available
expect(catalogApp.upgradeAvailable).toStrictEqual(expectation); | ||
}); | ||
|
||
it('if no version is available', () => { |
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 is the same as above (should it include catalogApp.spec = { chart: { metadata: { } } };
?)
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.
No it's not necessary for computation.
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.
to check explicitly for a missing version it would need to get passed the check for a missing chart and spec. so by providing the object above the test should hit the code that it's aiming to check.
as it stands the test is the same as for if no chart
and doesn't exercise anything different
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.
but the test is passing, otherwise we are missing one and I did not realize it.
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 two tests if no chart
and if no version is available
are exactly the same. both tests should provide and env such that only the condition referenced in the test title is exercised
repoName: 'rancher-charts', | ||
}, | ||
{ chartName: 'rancher-alerting-drivers' }, | ||
{ repoType: 'cluster' }, |
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 only repo type or repo name i don't think we should match any chart in that repo. feels like the minimum would be the chart name
It seems to crash just in case of lack of charts, so I omitted it. |
The sections where I previously had trouble with the
I didn't notice any issues here.
I did run into the issue with the copy-code.mp4 |
Closing since is outdated and replaced by a new issue: #11465 |
Summary
Fixes #9613
Changes are the same of #9806, except that
repoType
,repoName
,chartName
are not mandatory anymore, as they will just return no charts if none of the criteria is provided.If parameters are provided, only charts with all of them will be returned.
Occurred changes and/or fixed issues
Technical notes summary
Added tests for:
given only all matching parameters if provided
for Epinio case.given any matching parameter
for returning always charts if anything matches (reason this is reopened).Kubewarden installation
I have a 2 breaking errors when I try locally with master to install Kubewarden to reproduce the mentioned case:
addChart
says therepo
is actuallynull
After setting conditional variables it works, although I keep it for another time, since my PR covered already more than needed and the error is on master as well (also just when running locally).
Areas or cases that should be tested
Areas which could experience regressions
Screenshot/Video