Skip to content

Conversation

@jescalada
Copy link
Contributor

@jescalada jescalada commented Sep 14, 2025

Fixes #1150, built on top of #1166.

Not all tests were perfectly refactored from Chai/Mocha -> Vitest. Some required partial or total rewriting to get them to play nice.

Some tests, specifically the proxy-related tests (proxy.test.ts, testProxy.test.ts and most importantly testProxyRoute.test.ts) have been very problematic for some reason - the tests in testPush.test.ts seem to fail in the CI when some of the proxy tests execute prior. They fail on the first execution locally, and then pass without issue (maybe a caching/cleanup problem).

Coverage has dropped somewhat to 80.5%, but we should see an increase after removing unused/untested code such as plugin stuff.

Note that the CI is failing due to the new Blue Oak license.

jescalada and others added 30 commits August 24, 2025 09:39
Co-authored-by: j-k <[email protected]>
Signed-off-by: Juan Escalada <[email protected]>
Co-authored-by: j-k <[email protected]>
Signed-off-by: Juan Escalada <[email protected]>
Co-authored-by: j-k <[email protected]>
Signed-off-by: Juan Escalada <[email protected]>
Co-authored-by: j-k <[email protected]>
Signed-off-by: Juan Escalada <[email protected]>
@jescalada jescalada marked this pull request as ready for review October 14, 2025 04:07
@jescalada jescalada requested review from a team, 06kellyjac, coopernetes and kriswest October 14, 2025 04:16
@06kellyjac
Copy link
Contributor

I think we discussed "BlueOak-1.0.0" before and can add it to the licenses list

@jescalada
Copy link
Contributor Author

@pGrovesy @grovesy This is the other big PR that could use a review! 🙏🏼

Copy link
Contributor

@kriswest kriswest left a comment

Choose a reason for hiding this comment

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

A huge contribution (reading it took half a day!).

A few questions about type overrides as and whether some can be removed for type safety in the tests. The schema docs generator also needs to be run (type generator was run). There's also a few places you could use vitest's assert to simplify checks.

I spotted a number of things that aren't really within the scope of this PR and commented on them. If on reviewing them you agree, either you or I should create issues to resolve those.

"password": {
"type": "string",
"description": "Password for the given `username`."
},
Copy link
Contributor

Choose a reason for hiding this comment

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

Are you able to run the schema docs generator (gen-schema-doc) to add these properties to the config reference? Give me a shout if not (i.e. if you haven't got the python env setup needed to do so).

You have run the quicktype generator (generate-config-types).

const config = loadFullConfiguration();

if (!config.cookieSecret) {
throw new Error('cookieSecret is not set!');
Copy link
Contributor

Choose a reason for hiding this comment

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

We should possibly make cookieSecret required in the config schema. Currently none of the top-level properties are required... but then that lets you validate a file full of overrides (as long as the defaults cover everything that is actually required). However, its leading to our generated type for the config having these properties as optional.

This may be worth some further thought - we could have two top-level schemas (for the defaults and for override files) that reference the same defs for top-level properties I suppose. That would give us two different typescript types to use, as appropriate.

export const getSessionMaxAgeHours = (): number => {
const config = loadFullConfiguration();
return config.sessionMaxAgeHours;
return config.sessionMaxAgeHours || 24;
Copy link
Contributor

Choose a reason for hiding this comment

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

As above - no default needed if it has to be in the defaults and we have a type expressing that.

console.log('No commit message included...');
return false;
}
console.log(`isMessageAllowed(${commitMessage})`);
Copy link
Contributor

Choose a reason for hiding this comment

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

this is (existing) debug output, we should drop it or start doing a better job with logging!

Not a blocker for this PR, but a note to self/reminder

Copy link
Contributor

Choose a reason for hiding this comment

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

There are several other places that info on why the message has failed the check is just being logged. We should refactor this to return an error message or null and then carry that forward into step.log messages, as that'll make illegal messages way less annoying to debug and we can drop all the debug logging here.

],
},
});
expect(res.status).toBe(401);
Copy link
Contributor

Choose a reason for hiding this comment

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

This should probably be a 403 - not an issue for this PR

],
},
});
expect(res.status).toBe(401);
Copy link
Contributor

Choose a reason for hiding this comment

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

This should probably be a 403

Comment on lines +228 to +239
{
label: 'I am happy for this to be pushed to the upstream repository',
tooltip: {
text: 'Are you happy for this contribution to be pushed upstream?',
links: [],
},
checked: true,
},
],
},
});
expect(res.status).toBe(401);
Copy link
Contributor

Choose a reason for hiding this comment

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

This should probably be a 403

],
},
});
expect(res.status).toBe(401);
Copy link
Contributor

Choose a reason for hiding this comment

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

This should probably be a 403, etc. will stop marking them here

@@ -0,0 +1,35 @@
import { defineConfig } from 'vitest/config';
Copy link
Contributor

Choose a reason for hiding this comment

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

Should there be a vitest config file for the cli tests as well?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Migrate tests from Mocha + JS to Vitest + TS

4 participants