I’ve been a software engineer for many years, and the last thing I want to do is to open up another website just to manually upload a file somewhere to get a response.
Here at Tidelift we provide tools for engineering teams to analyze their dependencies, but until now that has either been through GitHub/GitLab hooks, an API, or opening our website and dragging a dependency file to our upload page in order to run a scan. We provide documentation on how to use our system with some curl script examples, but those are fragile, and, frankly, I don’t want to have to remember to update that -F “email@example.com” format every time for every new project.
Enter the tidelift CLI.
Last year, I was feeling adventurous and wanting to learn a new programming language. I tried out Rust and Go. I settled on learning Go, but what would I make? Using the “do what you know” methodology, I decided to try learning Go by making a fun tool for work.
I played with it for a few weeks. My tool would find all dependency files we support and gather those together and upload them to our tooling. It was a glorified curl replacement. Satisfied with that dopamine fix of making a new program, I put it down for a while.
Fast-forward to 2020: Our product team was contemplating adding features to our website where we have a catalog of supported packages, so we decided we wanted to write a command line application, and it would be in Go!
My heart skipped a beat and I exclaimed: “OMG I wrote a SFD of this last year! Let’s work from that!”
So I gladly transferred copyright of the codebase to Tidelift, and from there we had the basis of our new awesome tidelift command.
The primary focus of the command line tool is to decrease the time to value for developers. We chose Go because of how well it runs cross platform. We envision our clients to be running their code on a Mac or Linux machine 99% of the time, but we didn’t want to alienate any Windows users. Writing this in Python would have been another choice, but redistributing Python executables is troublesome and there are a few extra steps that Go just solves.
The application is a single binary (well, one built for each of the three major platforms) and that’s all you need to download. No complicated installs! The only configuration you need to do is to visit your subscriber dashboard, generate an API key for each repository you wish to have access to, and either set up some environment variables or configure your already existing .tidelift.yml file to point to the proper repository. That’s really it: three bits of configuration and you can quickly run tidelift scan.
The first thing we built was parity for our current system; you can upload dependency files, run a scan against those, and block your build process if the scan doesn’t pass. This makes the tidelift tooling a simple drop-in into your CI/CD process.
After one week of working on the tool, we even inserted it into our own CI/CD process and it only took changing a few lines (downloading the latest version, running the scan, and checking for a pass/fail) in our CI config files.
We believe that the Tidelift CLI is a tool that will make it easier for developers to consume managed open source. When used in a team or enterprise environment, this tool will allow us to provide guidance so that developers can safely ensure that they are using packages from your approved catalog. Writing a command line application allows developers to have minimal interruptions (one of our visions is that the tidelift command could be run as a git push hook, no need to visit our site every time!) and makes it easy to use safe and well maintained open source components.