chore(e2e): refactor smoke-test.ts structure COMPASS-8795 #6602
Conversation
| run_on: 'ubuntu2004-large', | ||
| depends_on: 'package-ubuntu', | ||
| }, | ||
| // { |
There was a problem hiding this comment.
Doing nothing will just fail now if we ever call smoke-test.ts. But we also won't call it until we update functions.yml to call it. So this is just wasteful in the meantime.
.evergreen/functions.yml
Outdated
| eval $(.evergreen/print-compass-env.sh) | ||
| if [[ "$IS_WINDOWS" == "true" ]]; then | ||
| // TODO: windows_setup |
There was a problem hiding this comment.
We could also just call the smoketest script for each of these TODOs now already because it will only be executed for mac. We'd just have to leave osx_zip out for now.
| .option('package', { | ||
| type: 'string', | ||
| choices: [ | ||
| 'windows_setup', |
There was a problem hiding this comment.
These are based on the naming convention in hadron-build. ie. in theory you can just do ${context.package}_filename to look up the filename for each of them.
| 'linux_deb', | ||
| 'linux_tar', | ||
| 'linux_rpm', | ||
| 'rhel_tar', |
There was a problem hiding this comment.
note that the redhat tarball is not named quite like the others because that's how it is inside hadron build already.
| }); | ||
|
|
||
| type SmokeTestsContext = ReturnType<typeof argv['parseSync']>; | ||
| type SmokeTestsContext = { |
There was a problem hiding this comment.
Is there a better way to infer this type from the yargs setup somehow?
| | { filename: string; installer: Installer; updatable: boolean } | ||
| | undefined = undefined; | ||
|
|
||
| if (context.package === 'windows_setup') { |
There was a problem hiding this comment.
This could also be a giant switch case or a hashmap to map these things or pluggable or.. I don't personally have a preference.
lerouxb
changed the title
Co-authored-by: Kræn Hansen <kraen.hansen@mongodb.com>
Co-authored-by: Kræn Hansen <kraen.hansen@mongodb.com>
Co-authored-by: Kræn Hansen <kraen.hansen@mongodb.com>
Co-authored-by: Kræn Hansen <kraen.hansen@mongodb.com>
Co-authored-by: Kræn Hansen <kraen.hansen@mongodb.com>
Co-authored-by: Kræn Hansen <kraen.hansen@mongodb.com>
We spoke about this and I need some amount of structure in place before we add the autoupdate tests. Would be nice to try and get it out of the way ahead of time so we don't have unnecessary merge conflicts.
This reduces the amount of parameters it takes considerably while still fitting in with our evergreen setup. The parameters we're left with are modelled after how hadron-build info works so we can still use that to calculate all the metadata we need, especially the relevant filenames. It should be a little bit simpler to use / work in locally too.
There's also a one-to-one relation between the script being invoked and which "package" (ie. osx_dmg) gets tested. I think it simplifies things a bit and makes it a bit simpler to work on locally.