All CLA requirements met.

No promises or anything, but I do have some comments about questions about what circle can do and our travis usage.

We use travis's cron feature to run our user-suite tests (we read an environment variable in the test runner to see if they should be included) once a day (this is configured on travis's web ui, which is why there's nothing in the config indicating it). Does circle ci have an equivalent feature?
Also, AFAIK, circle auto-caches node_modules dependencies and things between builds? Is there a way to purge this cache? We don't pin many of our dependencies (and prefer to be know when we break), but sometimes if we do get broken/break something, we may publish an updated dep (if we control it), and rerun a build - in travis we usually need to purge the cache when we do this.

Sure - so regarding Cron, CircleCI 2.0 does have this feature, we call it scheduled builds. If you can provide me more information about how you're going about that as well as the cron syntax you're using, I can update my PR with the CircleCI equivalent.

Regarding caching, CircleCI 1.0 would have automatically cached node_modules. CircleCI 2.0, which is what I'm using in my PR is more explicit. This PR does not cache anything except the Docker images in which the environment runs. That is, the raw Docker image, not anything in it as a result of the build.

If you did want to use cache, the new cache works on setting a cache key. Which can be based off node_modules, a hash of packages.json, the Git cache, or an external resource. We can discuss that more if curious.

This code is the place where we change our behavior for a cron build - we inspect an environment variable, as might be expected. (Otherwise we expect to be run same as a normal build)

@weswigham Hey so my new commit addresses your comments from yesterday.

Cron

I added the config for Scheduled Workflows which is our equivalent to Travis's Cron. This is a UI changed I had to do here. In CircleCI, I created a new context with the name nightlies and added the TRAVIS_EVENT_TYPE variable with a value of cron. This will cause builds to trigger at 12:00am PST a.k.a. 8:00am UTC.

workerCount

I did some research. Here's a comparison of CircleCI build times based on workerCount (asterisk means avg of two builds):

So this tells me that a workerCount of 8 is most efficient for these builds. However, the Node.js v6 builds fail with any workerCount above 4. So either, we stick to 4 or I adjust the config to set the workerCount to 8 for Node.js v9 and Node.js v8 and 4 for Node.js v6. With a workerCount of 8, we're looking at a total build time reduction of over 50% when compared to Travis, for Node.js v9 and v8.

Caching

Nothing with regard to npm/Yarn packages are being cached at all in my PR.

Again, all of these builds can be found here: https://circleci.com/gh/felicianotech/TypeScript/tree/circleci

Please let me know if there's any further questions or comments.

@FelicianoTech Is there some way we could get the custom log folds we had on travis back into the circle output (travis parsed the console output for some special identifiers to create folded sections with durations)? We've been using travis-fold and it's facilities or custom formatted strings to clean up/compact the output the way we like. TBH it's the only thing I can think of that's missing.

In short, no.

Travis CI's log folding feature we don't have an equivalent to. The closest thing I can think of, is in the UI we automatically "fold" the "Steps" that are defined in the CircleCI config file. We could separate npm test for example into its own step so that it could be "folded" separately from the commands before it. So this gets you part of the way there.

I believe the travis-fold npm module is being used to indicate custom commands to fold in your build output correct? That we wouldn't be able to replicate right now.

Personally, I have written a CircleCI Chrome extension that works pretty well and part of my goals for that is to test new UI ideas for CircleCI.com and GitHub.com. I've opened an Issue to investigate adding fold support via the extension in the future: FelicianoTech/pointless#26

I believe the travis-fold npm module is being used to indicate custom commands to fold in your build output correct? That we wouldn't be able to replicate right now.

Not custom commands, just specific sentinel text surrounding the desired fold; that's why you can have multiple folds in a single command's output (as we do).

Ah okay. Well we don't have an alternative to travis-fold. The rest of the features we do and with that the decreased build time.

🎉 we're going to give this a shot! Thanks a ton for the PR Ricardo 😃

I'm having trouble adding it to the repo 😕. I think this might be a Microsoft-wide permissions issue... Figuring it out with Wesley offline.

That's great news @DanielRosenwasser. Here's what needs to be done now:

• CircleCI needs to be added for this repo (which is free) (if there's any issues, let me or Support know)
• An org-wide context needs to be setup called nightlies with a variable called TRAVIS_EVENT_TYPE with the value of cron. Instructions here.
• PR Remove unneeded circleci branch in CircleCi config. #22017 should be merged because this PR was merged before those lines were removed.

Hey @FelicianoTech, we reached out to Microsoft's GitHub admins and have CircleCI running on master! Problem: we're not seeing how to enable this for our PRs within Apps & Services for our repo's settings. Any idea if this is another permissions issue?

It's all done on CircleCI.com. Add the project, then go to settings.

We have build forked pull requests on, but still aren't getting status badges from circle on PRs:

@weswigham Right now builds will only run for branches listed in lines 5-8 of the config:

        - master
        - release-2.5
        - release-2.6
        - release-2.7

That would need to be loosened if you'd like other branches to also run.

@FelicianoTech that whitelist also applies to forks? We want to build all PR-associated code (which is typically in a fork, but not always), plus master and our release branches (so we test post-merge).

Yes. That specifies branches, regardless of where they come from.

It might make more sense to just build all branches then? Or maybe just specify what not to build?

But then random branches we make on the repo that don't have open PRs would get builds. And swapping to only branches that have open PRs could miss building a (likely unintentional) direct push to master or a release branch (though is probably the best compromise...).

@FelicianoTech This is the best 'sales pitch' I've ever seen 👏