DCIY lets you do continuous integration testing locally through a web interface.

If you can run your tests for a project locally in the terminal, then you should be able to run CI with a web interface and keep track of build output locally too. DCIY does exactly this. There is no system for multiple users, or for managing SSH keypairs, or anything else—all DCIY does is provide a web interface for checking out Git repositories and running CI on them, all as the same user (you) that is firing up the DCIY server.

I started this project because I wanted to run CI on some other private side-projects I’m working on, and couldn’t find anything else lightweight enough that suited my needs. It is not intended to be a a fully-fledged, production-ready CI environment, so if you want something more that’s also free, you should check out some of the following projects:

• Travis CI - If your project is public, this is probably your best option.
• Strider CD - An open source continuous integration & deployment server written in Node.js.
• Kochiku (by Square) - An open source distributed testing platform.
• Jenkins CI - Might be ugly, but it’s open source, widely used, and has a large following.

DCIY runs all commands on your behalf, so it’s probably not a good idea to use DCIY in situations where you’re concerned about security. It is your responsibility to ensure that you trust the contents of the branches you build, and that you shut down the DCIY server when you’re not using it.

I’d love to find ways of making this less of an issue in the future, such as providing a way to easily sandbox the build process (using some combination of technologies like Vagrant and Docker, maybe?), but even if that happens, it’s still important to be aware of what code you’re running on your machine.

Run these commands from your terminal to get set up for hacking on this locally:

git clone https://github.com/cobyism/dciy
cd dciy
script/server

The script/server command should do all the bootstrapping and process starting necessary, and should give you a DCIY server running locally on at the following address: http://localhost:6161.

Go to the root URL or /projects and click "New Project", and type in the <owner>/<repo> part of your GitHub project (leave off the https://github.com and the .git parts). Submitting the form will give you a new project which you can run builds for.

By default, DCIY will build your project by executing a file called script/cibuild. If you'd like to override this and customize your build, add a file called dciy.toml to your project's top-level directory. dciy.toml uses the following format:

[dciy.commands]
prepare = ["script/bootstrap"]
cibuild = ["script/cibuild"]

You can specify more than one command for either of the steps by just adding elements to the array:

[dciy.commands]
prepare = ["bundle install", "bundle exec rake db:migrate"]
cibuild = ["onecommand", "anothercommand"]

Any commands listed in prepare are run first, followed by the ones specified in the cibuild array. A build is marked as successful only if all of these commands exit with successful (zero) exit statuses.

Each time that your project is checked out, the dciy.toml file is rescanned for changes, so all you need to do change your build is commit the updated command and DCIY will know about it the next time it tries to build your branch.

Go to /builds and click "New Build". Enter the branch name or commit SHA that you want to build the project at, and submit the form. DCIY will then go off and do the following:

• cd into a workspace directory for that project, or clone it down if it hasn’t seen it before.
• Run a git fetch to make sure it has everything locally it needs.
• Checks out the project at the specified branch or commit.
• Initiates and prepares submodules, if there are any.
• Uses your build configuration to run the project's test suite.

Keeping an eye on /builds will show you the status of the build as it runs in the background, and you can click on the build to view the output once it’s finished.

To use DCIY with a project on a GitHub:Enterprise instance, add a line to your .env file like so:

ENTERPRISE_HOSTS=github.starship-enterprise.com

Now, when you're creating or editing projects, you can choose github.starship-enterprise.com as a GitHub host.

I’d ❤️ to receive contributions and feedback from anyone, and there’s more ways to do that than writing code.

1. Fork the repository.
2. Create a branch (e.g. my-awesome-feature) for the work you’re going to do.
3. Make your awesome changes in your topic branch.
4. Send a pull request from your branch to this repository.

• Try the project out yourself.
• File issues about bugs, problems, or inconsistencies you run into.
• File issues with suggestions, feature ideas, or UI mockups for improvements.
• Read through the documentation (just this README for now), and look for ways it could be improved. Click "Edit" on the file and make the changes yourself if you can!

MIT.