Is there a getting started guide for CircleCI for Meteor?

testing
1

I have seen this forum post reply by @mitar : Testing a Meteor Package with Velocity / Tinytest.

Is there more somewhere?

1 Like
2

We use this package: https://github.com/tozd/meteor-test-runner

3

Yes, I saw that. But it has no documentation at all. Do I just copy it into my project directory, commit it to GitHub and let CircleCI work out what to test?

4

We add it as a git submodule under tests/test-runner and then have the following circle.yml:

checkout:
  post:
    - git submodule sync
    - git submodule update --init --recursive
machine:
  node:
    version: 0.10.33
  pre:
    - curl https://install.meteor.com | /bin/sh
dependencies:
  override:
    - npm install selenium-webdriver
    - meteor list
test:
  override:
    - tests/test-runner/test-all.sh

Ah, and this is for projects. So we have all code in our projects inside packages. So it tests by going through all projects.

For testing a single package in the current directory you should probably run tests/test-runner/test-package.sh ./.

5

Good that helps. Thanks.

6

@mitar Thanks again for getting me going.

So . . . I repackaged https://github.com/tozd/meteor-test-runner into this Quick start tool for running TinyTests in CircleCI

Should I make a pull request, or is it too rearranged to still fit what you have?

7

Interesting. Could you maybe split this into two packages? So you send to meteor-test-runner package better documentation, example yml and things like that. And the installer and uninstaller could be in Meteor Tinytest Runner. So I think this would be a good separation, what do you think?

8

So I would be sad if packages would now diverge. So we will be probably upgrading and improving it. CircleCI has a nice API so you can hook into its API and get nice output and stuff like that. So there are some further improvements planned. But yea, we use this internally and do not have much free cycles to provide nice user friendly support for it. Sorry.

9

I would not like to see a divergence either.

Do you see that I changed the directory structure? My purpose was to make it so that it can drop into place in any Meteor app that has a tests subdirectory, while remaining encapsulated and out of the way… If you can absorb that change, then I see no problem in accessing your package as a git submodule.

├── meteor-test-runner
│   ├── configs
│   │   └── circle.yml
│   ├── runner.js
│   ├── test-all.sh
│   └── test-package.sh
│
└── meteor-tinytest-runner
    ├── example_circle.yml
    └── tests
        └── tinyTests
            ├── runner.js
            ├── test-all.sh
            └── test-package.sh

I also changed how to invoke meteor. CircleCI caching of the meteor installation failed without the change.

In test-package.sh this …

   meteor test-packages --once --driver-package 'test-in-co etc etc

… became this …

   .meteor/meteor test-packages --once --driver-package 'test-in-co etc etc

If you need it to stay the way it was, I could try adding .meteor to the PATH env var.

10

Do you see that I changed the directory structure? My purpose was to make it so that it can drop into place in any Meteor app that has a tests subdirectory, while remaining encapsulated and out of the way… If you can absorb that change, then I see no problem in accessing your package as a git submodule.

I don’t understand this directory structure change. So why wouldn’t you use it as a git submodule under something like tests/test-runner when adding it to any Meteor application? So the example configuration under configs/ is there just as an example to see how to use it. You need to copy that to your project root directory anyway.

So the other changes regarding improving caching and adding documentation seem ok, so we can merge those if you make a pull request with just those changes.