Migrate from TravisCI to CircleCI

[inkel]

Continuing discussion started in https://github.com/citrusbyte/itv-calendar/issues/292

[inkel]

From what I can gather it seems it's a matter of setting up the project on CircleCI and then updating the config.yml file mimicking the configuration found in travis.yml.

[abelino]

I think I might have overlooked the travis.yml but if this project already has some ground work for CI, isn't it best to reuse that? I don't have a preference between any CI/CD runner. What do you think @arecvlohe ?

[arecvlohe]

I think that sounds good to me. But do we want to split builds up in the same we have them in itv-calendar with staging and production? I imagine we will reuse some things but I am wondering what needs to be, or will be, different.

[inkel]

I agree that sticking with TravisCI will be the easiest thing to do. I don't think we have an account with them, but we could create one, I guess.

@arecvlohe I'm trying to understand what do you refer about split builds. I'm still not sure what is that you fellas are trying to achieve here.

[abelino]

I suppose the staging, development, production doesn't apply here. Since this is just a lib. Granted it is a huge portion of our main application but I don't see the need here. I do see the immediate need to run the following (and please add if you see other things that I missed):

• As branches/commits are pushed to github:
  • linters or yarn format should run to simply detect if changes have been made, if some files where modified then this means the user failed to run yarn format before pushing; at this point CI should fail
  • run tests and proceed accordingly
• Merging to master should prob trigger a new generation and deployment to GH pages?
• Merging to master should not trigger a deployment to npm IMO; but we can do something like create a branch release/1.2.1 off latest master with version bump changes in package.json and other release related changes; changelist etc... AND once this gets merged to master; travis should deploy to npm?

^^ ALL SUGGESTIONS :) please do let me know what you guys think. @inkel @arecvlohe

[arecvlohe]

I agree with @abelino here and I retract my thoughts on splitting the builds as we did with itv-calendar. What I agree with are:

• CI builds for each push
• Merging to master triggers a new deployment to GH pages. There is a CLI tool for this.

I do think a merge with master should kick off a publish to NPM unless this is too much work. We have been using np, aka better npm publish, for this and it does the whole version bump and commit. But this can be done separately as well if it is easier. I don't have much experience deploying a lib so it would be good to gain insight from those who have.