Continuous Integration

[00:00:00]
>> One of the final things I wanted to cover before we do continuous integration is NPM scripts. So NPM scripts are a way for you to kind of have little pieces of automation that are gonna be set for your package. So if I have a module, like here I'm gonna just hop into a real one, you can have different scripts like if we wanna run the tape command for a test suite.

[00:00:26]
You can install it as a dev dependency, which shows up in the package JSON right here, and then whenever I run NPM test, this command is gonna run. So there's a few special cases for NPM, things like npm test and npm start will automatically run the command in scripts called tester start.

[00:00:49]
But you can put more things like for example, if you wanna put a build script in there, you could call it build, or watch, or dev, or whatever you like. Or prod for production build. If you do npm run in front of that name, then it will run it, so you can use npm to running your stuff.

[00:01:07]
That's how that works. If you want to set up your system for continuous integration, you'll have to probably include an NPM script to run your test suite. So here I have a real demo, so this repository currently doesn't have any kind of continuous integration, although, it does have a test script.

[00:01:35]
So in this case, I'm even setting an environment variable because this module uses dates and times, and that kind of stuff. And I was in the Pacific Time Zone when I wrote it [LAUGH] so you have to be in the Pacific Time Zone for all of my test cases to work.

[00:01:52]
It actually doesn't completely work, I think because of some daylight savings issue. Now that it's either daylight savings, or not, I don't know exactly, but it's one of those things. So one of the cases actually doesn't work right now, which is fine because we can now set up some continuous integration on Travis CI.

[00:02:15]
So what that looks like is every time I push code to GitHub in this case, then Travis CI is watching for changes. And it will automatically download my entire code suite, run NPM install, and then it'll run NPM tests. And so, I can put a badge in the read me that looks like this, or so I can show you on real package what that looks like.

[00:02:47]
So on a lot of packages, you might see these little icons like build passing, if my tests aren't working on CI, this badge will turn red. So it's kind of a handy way to know that your tests are failing, if you're not reading your email or you're not doing other stuff.

[00:03:08]
It's also a way to communicate to users of that library that yes, in fact, this piece of code works and its solid. So to set this up, what you can do is you can make a file that's called .travis.yml for YAML which it's this weird old JSON. That's popular still in Ruby land, maybe I don't know.

[00:03:28]
Anyways, so you can copy and paste this chunk of text, which is pretty good for most node packages. If you need to do things like install system scripts or whatever, there's a lot more settings that you can configure. In this case, I don't need to do anything like that.

[00:03:42]
So I'm gonna save that to .travis.yml, so we can see in this file, oops, that this is a node project. So Travis is clever enough to know that it needs to run NPM install and NPM test, which is gonna run our package JSON scripts that uses tape. And then we can specify the versions of node that we wanna test on.

[00:04:08]
Okay, so you have to commit that file to your get repository, And probably as well, you wanna put in a little badge here, so here's what that looks like. So remember to change substack/node-browserify for whatever your package is called and whatever your username is called. So I can replace, I'm still sub stack on GitHub so but I can replace browserify with parse-messy-time.

[00:04:41]
Make sure to do it twice because there's two of them in this batch, parse-messy-time. Okay, so So now we're using Travis CI, the final thing that I need to do is, you'll have to go to travis-ci.org, and create an account. I think you can log in with GitHub, if you're already have an account there, then you can go to this URL for your username and your repository.

[00:05:11]
So I'm gonna go to substack/parse-messy-time, which is the name of this project that I'm gonna configure. And then there should be a button called Activate repository, it's this blue thing down here, so when you click that after the page loads. Now the next time that I push code to that repository on GitHub, Travis is gonna check out that code, and it's gonna run my tests.

[00:05:44]
And if they all pass, I should have a green badge, if they're failing for whatever reason, maybe I forgot to add a dependency, all kinds of reasons why it could fail. Then it's gonna be a red badge. In this case, it will most definitely be a red badge because I already know running locally that the tests are broken.

[00:06:03]
So here we have the output, and if you click one of them, you can see kind of the test results as they stream in. So it does take a little bit sometimes, but it's downloading various things from the internet, it's quitting my repository. It's standing up node and running NPM install, which we just did, and then it's running NPM test.

[00:06:25]
So here we have the tap output, I'll try to make that bigger, the tap output, that should be very familiar. It's in mobile mode, there we go. So it set the timezone, and now it's running through the test cases, and there's a failing test. So that's gonna set the exit code to be non 0, which is how Travis knows, here it says, the command NPM test exited with 1, so the test failed.

[00:06:51]
And there should be now on that repository, the badge should be red, so I'll go to the pearse-messy-time on GitHub. I look at the readme, both failing, so I can now go in and fix that test case, what I'm actually gonna do is not to fix it, I'm just gonna disable that test case.

[00:07:13]
So this one is 30 in 1.5 weeks, It just to show you what the workflow is like once you fix something, so in 1.5, so there it is in pearse.js, in 1.5. So I'm just gonna turn this test off. Which is not something that you should actually do, but everyone does it anyways, so I might as well show you what it's like.

[00:07:48]
Turn a failing test off, and now once you push to GitHub again, now Travis is gonna be listening for these updates to roll along. And if I go to the Build History, we should see the next build, there it is. So if you click that, we can see all of the different versions of node.

[00:08:16]
And there might be an issue where you're using an API that's only present on the latest version, but not in older versions of node, so it's good to check that kind of stuff. So here, we're running through. Unpacking replacement, let see all kinds of fun stuff, string that get cloned.

[00:08:37]
There's the progress part that looks pretty terrible because we're viewing it on a web page, and running NPM tests. So now it's going through all of the cases, now the exit code was 0, so the test passed. And I bet if I refresh this now, yeah, it's green now, great.

[00:08:58]
So that's kind of the basic workflow for setting up CI on a project once you have some tests and once those tests are in your package JSON scripts. That is all I have for this section, so I guess in the time before lunch, you can try out some of these packages.

[00:09:19]
So I covered file and also NYC which you can try out, and then you can maybe create a repo of your own. You can add a test script into package JSON, and you can try to get it set up with Travis CI if you want. Or you can just make a dummy project that just does almost nothing, that's a good way to test out how to use Travis.

[00:09:47]
You could even copy some of the test files that we already have in here. Some other tips, make sure if you are gonna set up your own repository, if your NPM install with --save-dev. Or there's a shortcut called -capital D, these mean the same thing. Tape, then that's gonna install tape into your package JSON dev dependencies field, which is needed by Travis CI when it installs.

[00:10:15]
So that it has the right library that's necessary for testing.