The stubbing setup actually worked pretty well for a while, despite its hackiness. (The 2.3 failure was a simple type error.) Second problem: testing the CLI # run tests as normal, assuming a real Keybase installation $ rake test # run tests with Keybase stubs $ TEST_NO_KEYBASE =1 rake testīoth of these were placed under the make test target, to prevent me from accidentally introducingĬhanges that broke one or the other while developing locally. Thus, there were two ways to run the unit tests: I completed my first version of this on August 1, and you can (testing for a keybase process or similar) Avoid require-ing any KBSecret or Keybase files that would throw exceptions on load.Stub out calls like Keybase.current_user with "dummy".Create a temporary directory somewhere and pretend it’s the KBFS mount.Check for the presence of TEST_NO_KEYBASE in the environment, and….
At a high level, the stubbing looked like My first approach to running the KBSecret tests on a CI was to abandon Keybase entirely, andĪttempt to stub a subset of Keybase functionality 2. Auto-generated coverage reports are also nice, as they provide a Impossible to forget to run your tests, 1 and they give new contributors immediate and automatedįeedback on their changes. However, I really like farming out the work of testing to a CI service - CIs make it I canĪutomate the suspension of my own (real) KBSecret state, and I certainly have Keybase and KBFS
Keybase install update#
Update (5/16/18): Much of the information below is now obsolete, thanks to the new keybase oneshotĬommand. This whole post expects you to have Keybase and your Dotfiles repository up and running.Keybase on the CI ENOSUCHBLOG Programming, philosophy, pedaling.
Keybase install how to#
Sidenote: Find out more about Keybase and how to install it. The general idea is to put all private files into this encrypted Git repository and symlink them from there to the local home directory. You can be certain they’re safe, not only from prying eyes, but also from malicious people who might try to change your code. They’re 100% private, encrypted, and verified. These repositories are real Git repositories but you can view them in the Keybase app. Keybase (a secure messaging and file-sharing app) added encrypted Git repositories to their offers a while (some years) back. Which brought me to an idea that I implemented today: Using an encrypted repository with all my keys, passwords, and (Ubuntu based) secrets. But also would it have been “private” on Github, it would only have been as private as possible until the next human error (me accidentially making it public) or hack (someone gaining access to my repositories). Obviously it’s a bad idea to add secrets, keys and passwords to a public repository. One problem though were API keys and secrets that, while I had a backup, didn’t make much sense to be added to the repository. I can re-install the programs I use and their configurations and setups with a single command. dotfiles and my own implementation at a later point, for now, just know, that it’s a backup of my home directory and settings for pretty much that is happening on my (Linux based) computers these days. While that sounds like hard work it isn’t much of it due to my dotfiles repository. For reasons I don’t want to go too deep into (I once again violated my rule to NOT install Ubuntu versions without a LTS in their name and ended up without eyes or ears) I had to reinstall my workstations and computers last week.
0 kommentar(er)
