Continuous Integration

Setting up Continuous Integration on binstar

Binstar build is currently in development

Navigate to the project settings

For the following example, we will use the user sean and a base project testci:

Log in to github from binstar

From your settings page enable binstar to access your github account.

Continuous Integration Settings

Select the github repository

You must navigate to your binstar package's continuous integration settings page. the url will be somthing like this: In your case you will need to replace sean/testci with your package.

Continuous Integration Settings

The fields:

  • Repository: The github repository you want to build. In this case it is srossross/testci
  • Run tests only on these branches: A regex that matches the git refspec you want to be build. Note: that this refspec is only tested, no build_targets will be uploaded
  • Run full build on these branches or tags: A regex that matches the branches or tags that match this refspec will also upload distribution files to binstar using binstar upload. These are the files which will be conda and pip installable.

Add .binstar.yml file to your repository

In order for Binstar to build your project, you need add a .binstar.yml file to the root of your repository. To do this run binstar-build init in the root repository commit the file and push to the github repository. See all of the .binstar.yml configuration options.

If .binstar.yml is not in the repository, is misspelled, or is not valid YAML, this will show up in your dashboard as a build error.

A simple .binstar.yaml example:

project: testci
    - echo "Hello Binstar CI!"

Private Keyfiles

Sometimes it is necessary to use private keys to build your package even though the repository is public. This is often the case when creating interfaces for web services. For example, boto is a Python interface to AWS and for full integration testing it requires valid AWS credentials/keyfiles.

Binstar allows to you submit private keyfiles which will be copied to the build machine. This means no private data has to be stored in your github repository and you can develop valid CI tests, which depend on private data, without worrying about information leakage.

To do this run the command:

binstar-build keyfile user/package 'remote-filename' --upload local-filename

Keyfile Example:

Using boto as an example of a project which needs valid credentials for CI testing, we first create a test user credential file named boto.config. Here are the contents of that file:

# File boto.config
# Test User Credentials
aws_access_key_id = XXXXXXXXXXXXXX

We can now run:

binstar-build keyfile sean/testci '~/.boto' --upload ./boto.config

This first uploads the contents of ./boto.config to the binstar package sean/testci and tells binstar that it should download the contents of the file boto.config on the build machine as the file ~/.boto for all builds of testci

To view the keyfiles for this build run:

binstar-build keyfiles sean/testci

当前网页内容, 由 大妈 ZoomQuiet 使用工具: ScrapBook :: Firefox Extension 人工从互联网中收集并分享;
若有不妥, 欢迎评注提醒:


订阅 substack 体验古早写作:

点击注册~> 获得 100$ 体验券: DigitalOcean Referral Badge

关注公众号, 持续获得相关各种嗯哼:


关于 ~ DebugUself with DAMA ;-)
公安备案号: 44049002000656 ...::