Information, resources and conventions concerning cherrymusic development
res/devel.html as input and creates
res/main.html as output. If you open cherrymusic in the browser, you get the compiled version as default. (you'll notice that all js files are replaced by only one file called
You should never make changes to the
res/main.html since it is auto-generated, so any changes to the main.html will be overwritten by the deployment script. Furthermore, there are some mustache HTML templates that might be of interest which are used mostly in
res/mediabrowser.js to render search results.
If you want to make any changes to the frontend you should append a GET parameter
devel=True to your URL, e.g.
localhost:8080/?devel=True. This will give you the undeployed version of CM, which contains all the JS files and less-css imports and the less-css compiler. Since the less compiler is distributed with CM, this allows for quick changes. We have a not-so-strict naming scheme for all the less-css. If you're curious, the modded parts of bootstrap are:
The deployment script
lessc have to be in your
You can make changes, test them and submit them without having installed the deploy requirements using the
devel=True GET parameter.
For the location of files and resources, check out the [CREATE PAGE: Package Structure] page.
The CherryMusic server code resides in the
cherrymusicserver package. For an overview of CherryMusic's files and resources, see the
[CREATE PAGE: Package Structure]
To run tests, the following modules are required:
runtests script is responsible for running the test-suite (on unix-y systems). If the
coverage module is installed, a minimum coverage requirement is enforced to ensure test coverage does not decrease.
Usage: runtests [-d OUTPUT_DIR] [TARGET] -d OUTPUT_DIR if given, write HTML coverage report to this directory, creating it if necessary. TARGET if given, only test the module "cherrymusicserver.TARGET" by running "cherrymusicserver.test.test_TARGET". Full coverage is required in this case.
As an alternative,
nosetests can be run in the project directory. This is what our travis setup does.
There is also the [
pre-commit] script, which can be used as a commit hook to automatically run tests before a commit gets created. To use it, place an executable symlink of the same name into
travis-ci tests certain branches after commits to github.
.travis.yml contains the relevant configuration. There are browser plugins to display project build status while browsing github.
[ci skip] to the commit message to skip a CI build for a commit.
Here's the recommended way to create a new release from the current devel branch.
Create release branch
$ git checkout devel && git checkout -b release
Bump the version
Create the release commit
$ git commit --all -m "version X.Y.Z"
Create annotated tag with release number
$ git tag -a "X.Y.Z" [-m <MESSAGE>]
master, then push.
$ git checkout devel && git merge release \ && git checkout master && git merge --ff-only release \ && git push --tags origin && git branch -d release