-
Notifications
You must be signed in to change notification settings - Fork 0
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
feat(cli): Add a CLI to build deep-links to Central ELK #36
Conversation
7742d51
to
6f5f177
Compare
Adds a (Deno) CLI tool to build a deep-link to Central ELK, and open it in user's browser.
516affe
to
e87a6cb
Compare
de07cae
to
2fbfc97
Compare
cli/deno.json
Outdated
@@ -0,0 +1,6 @@ | |||
{ | |||
"tasks": { | |||
"compile": "deno compile --allow-run=open --target aarch64-apple-darwin --output dist/devx-logs index.ts", |
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.
Only compile for M series macs, because as a department, that's what we use for local development.
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 resulting binary is pretty big for what it does (>100MB). We could use bash instead of Deno, however we'd lose type-safety etc.
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's because the Deno runtime has to be shipped within the binary. Can't be helped unfortunately (:
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.
If we're compiling to a specific arch anyway, is it worth using a compiled language like Rust or Go instead? Would likely cut down on the runtime size significantly.
Or compile to JS and run with the users existing node binaries?
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.
If we're compiling to a specific arch anyway, is it worth using a compiled language like Rust or Go instead? Would likely cut down on the runtime size significantly.
Chose TS on the assumption that it's the most familiar across the department (other than possibly Scala). If we move to JS, we could probably distribute this via NPM, rather than homebrew?
WDYT?
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 haven't worked with it much, but deno install
could be a nice middle-ground, which wouldn't require much change to the code? https://docs.deno.com/runtime/manual/tools/script_installer
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.
@bryophyta my understanding is that install
would create a script that invokes the CLI using deno
. That means that people would have to have deno installed in order to run the CLI, since the runtime is not included.
I don't think we should require people to install additional software when running CLIs (which is why I'm personally averse to CLIs that need, for example, the JVM to run). I would rather have a 100MB standalone executable that's easy to distribute - I don't see it as different from a huge Electron app (which we've pretty much accepted as the norm).
As Ash says, there are languages there are better suited to writing CLIs, but Deno is a good compromise imho, since TypeScript is pretty much understood by everyone at the G.
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.
We distribute our dev tooling via homebew. I'd be keen for this to also be distributed the same way, to reduce cognitive load. Homebrew formulae supports the idea of dependencies, so we could craft this such that the raw TS files form the Homebrew artifact, and we have a dependency on Deno. Theoretically this would provide the same benefit as distributing a binary - the reduction of "works on my machine" symptoms.
I'd suggest we ship as is, and revise our approach once we understand what to optimise for (disk usage, performance, maintainability, etc.). Our work laptops have quite a lot of storage (1TB), and I'd be surprised if ~100MB is noticeable.
WDYT?
4193945
to
ef05394
Compare
@akash1810 I think you may be missing changing |
This CLI is written with Deno, rather than Node. AFAICT Deno isn't yet supported by Snyk. |
This'll allow `main.ts` to be unit tested.
export function removeUndefined( | ||
obj: Record<string, string | undefined>, | ||
): Record<string, string> { | ||
return Object.entries(obj).filter(([, value]) => !!value).reduce( |
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 think this would stop you for filtering for any values that are 0?
!!0 == false
!!1 == true
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.
You're correct, however removeUndefined
takes a string, and !!"0"
is true
... because JavaScript...
![image](https://private-user-images.githubusercontent.com/836140/291570332-910ce3d4-cdb3-41ec-854d-74094cffcea0.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Mzg4NDgzNjYsIm5iZiI6MTczODg0ODA2NiwicGF0aCI6Ii84MzYxNDAvMjkxNTcwMzMyLTkxMGNlM2Q0LWNkYjMtNDFlYy04NTRkLTc0MDk0Y2ZmY2VhMC5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUwMjA2JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MDIwNlQxMzIxMDZaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT02ZGU0NjUxNjFmYTU5MTI5Y2FkZGVkYmUzMDkzYTYxMzBjMDdjNDE2NzgwMTFkYzc4OTgyOGZjMDYyOWU3MmIxJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.GCNzASi99MD-yETIqil12SpgHCRPLwQfl1IuRFygw-Q)
I've added a unit test for this now too - 824038d.
What does this change?
Adds a (Deno) CLI tool to build a deep-link to Central ELK, and open it in user's browser.
How to test
cli
directory, rundeno task demo
to view the logs for Riff-Raff PRODcli
directory, rundeno run main.ts --help
and follow the instructionscli
directory, rundeno task compile
then run./dist/devx-logs --help
and follow the instructionsNotes
We don't yet have a defined vulnerability scanning story for the Deno ecosystem, so I've deliberately opted to use the standard library, and no third-party dependencies (cc @guardian/devx-security).