kraen.hansen@mongodb.com  and I had a zoom chat about smoke-test.ts now that something is in there. Here's my attempt at trying to summarise. Which might be biased. Let me know and keep me honest

I think we can get rid of most of the env vars / cli parameters in smoketest.ts if we just take platform, arch and package where package has values like windows_setup, windows_msi, windows_zip, osx_dmg, osx_zip, linux_deb, linux_tar or linux_rpm, rhel_tar. Then we can still use hadron build info to calculate all the filenames for us because the keys are just ${package}_filename . If we're willing to duplicate the code that calculates all the filenames, then we probably have other options.

We then still need devVersion or DEV_VERSION_IDENTIFIER or just version so we can calculate these for an arbitrary version, probably falling back by reading it from package.json like we do now for when you test a local build or beta or stable. Would have to double-check that that would work for beta, though.
platform, arch and version is enough to be able to run hadron build info.

We can then do away with isWindows, isOSX, isRHEL and isUbuntu. also with extension. And the package filtering. ie. there wouldn't be a loop. we'd test osx_dmg and osx_zip as separate invocations of the script.

We still need bucketName and bucketKeyPrefix for downloading a dev release. I think it will work for downloading a beta and stable package that was just built in that CI run too. We might need different parameters to determine the most recent dev/beta/staging release to download. Or at least to know which of the three we're looking for. Unless we infer that from the version or something in the output of hadron build info? There's a channel variable which is exactly it.

Oh we also need hadron build info or similar in order to be able to work out buildInfo.productName / appName. ie. MongoDB Compass Dev vs MongoDB Compass Beta or just MongoDB Compass . If we don't use hadron build to work that out we have to duplicate that too. You get it for "free", though. It works that out from the version or something.

In the end I think we probably want to continue to use hadron build info, so basing our input parameters around that makes sense.