smarterclayton / openshift-cdk-cart Goto Github PK

OpenShift Cartridge Development Kit - start building cartridges on OpenShift today

Ruby 73.69% Shell 26.31%

openshift-cdk-cart's Introduction

OpenShift Cartridge Development Kit

Make building and testing cartridges easy on OpenShift. The CDK runs as a cartridge on any OpenShift server supporting downloadable cartridges (Online, Origin) and can host the builds and source code of your application.

Installing the CDK

To get started, create a new app in OpenShift that uses the CDK cart:

rhc create-app mycart http://cdk-claytondev.rhcloud.com

Once the app is created, check your cartridge source code into the Git repository. If you want to fork an existing cartridge, just use the --from-code option. For example, if you wanted to fork the Go cartridge:

rhc create-app mycart http://cdk-claytondev.rhcloud.com --from-code=git://github.com/smarterclayton/openshift-go-cart.git

After the create completes you can visit your CDK app in the web, and you'll see information about your Git repository. The CDK will show info about your cart by reading your manifest.yml and build scripts.

Creating your own cart

The best reference right now is the cartridge writers guide. More docs and tutorials should be available soon.

Building your cart

If your cart needs to compile source into binaries in order to run on OpenShift, you'll want to execute a build. Like any other OpenShift application, your build hook is at .openshift/action_hooks/build. After checking in a build script and pushing your changes to the app, hit the app in the web.

You'll see a 'Builds' section with a form. In the form, enter the version of the cart you want to build (usually your master branch, but could be any other commit) and hit "Build Now".

By default, the CDK generates a password for you when you install it. This prevents people from running builds arbitrarily. The password is stored in the gear as an environment variable - to see it run:

$ rhc ssh mycart --gears 'env | grep CDK_PASSWORD'
lotsofrandomcharacters

When prompted for your password, enter "admin" as the user and the value you printed above as your password.

The CDK will now build your cart and display any output directly in the browser. The build will be stored on disk in your app.

Hit back and refresh the CDK page to get the latest build. Copy the build link and use it to create another app:

rhc create-app myapp <build_link>

rhc add-cartridge <build_link> -a myapp

If you want to debug the output of a build, SSH in to your app and run the build script manually:

$ rhc ssh mycart
Connecting to ....
$ cd $OPENSHIFT_REPO_DIR
$ .openshift/action_hooks/build

Future Features

Check your manifest for syntax errors and other common problems
Example cart manifests for different types of carts
Helpful scripts you can run while in the gear to debug problems or test changes
An acceptance test suite for cartridges

Pull requests welcome!

openshift-cdk-cart's People

Contributors

Stargazers

Watchers

Forkers

xltian a13m mfojtik cloudstrap britztopher fernandohc gabrielcury jwforres pilchardfriendly librucha bran921007 atomlaw trifonnt noroutine acrollet saclayen weaver-viii dev-alex-alex2006hw bume1029

openshift-cdk-cart's Issues

problem creating a cdk with go cartridge

I have a problem to create the cdk with go cartridge as described on the README

08:37 $ rhc create-app cdk http://cdk-claytondev.rhcloud.com --from-code=git://github.com/smarterclayton/openshift-go-cart.git
The cartridge 'http://cdk-claytondev.rhcloud.com' will be downloaded and installed

Application Options
-------------------
Domain:      value
Cartridges:  http://cdk-claytondev.rhcloud.com
Source Code: git://github.com/smarterclayton/openshift-go-cart.git
Gear Size:   default
Scaling:     no

Creating application 'cdk' ...
The server did not respond correctly. This may be an issue with the server configuration or with your connection to the server (such as a Web proxy or
firewall). Please verify that you can access the OpenShift server https://openshift.redhat.com/broker/rest/domain/value/applications

Delete old builds

Please allow admins to delete old builds (and the abandoned working dir / temporary archive of failed builds) without having to log in over SSH and find them.

Build Flavours

I have a cartridge which is build in multiple flavours, by making small changes to the source. This is currently done by keeping the patches for each flavour in a branch, and whenever I commit to master, I rebase all the branches.

This has two disadvantages:

The rebase often fails to merge automatically, so I have to manually intervene for every branch.
Old branch builds can no longer be identified, as their SHA no longer matches any changeset. This means that there are no usable cartridges between pushing the rebased branches and rebuilding them all, which can take several hours.

Some possibility of customising the build at runtime would seem to be the solution. Parametrised builds may be against OpenShift's philosophy, but I could try imitating this with an environment variable. However, the CDK doesn't support multiple builds of the same changeset, and even if it did, there would be no way to tell which parameter it was built with.

Perhaps the CDK could take a single text parameter when triggering a build, store it in a known environment variable, and label the build with it (it would have to be included in the filename as well).

Zip file created should respect symlinks

The zip used by the build process creates copies instead of a zip with symlinks. This increases the zip size, and leads to broken behaviour when cartridge control scripts follow symlinks (rbenv, ndenv, etc).

Build logs

The build log is shown after requesting a build, but doesn't seem to be kept anywhere.

Build in a background process

Builds seem to be abandoned if the client connection is lost (a common occurence with flaky wireless). The experience would be much better if builds ran in the background, and the request just returned a link to the log.

Jenkins builds

Would it be possible to build cartridges with Jenkins? My reasons for wanting this are:

One medium gear could serve multiple CDKs as a build slave, and would only be created when needed.
Serving and building cartridges won't be competing for the same resources.
I have several cartridges based on the same source, and would like to schedule a build for all of them to test changes.
Not running Sinatra in the background might leave more memory for builds, but I haven't benchmarked whether this is significant.

Builds that take longer than 60 seconds can abort

I'm creating a cartridge that runs npm install - leading to compilation of many native npm dependencies. This can take longer than 60 seconds.

Puma seems to kill workers after 60 seconds by default - it would be great to increase this timeout to, say, 5 minutes.

I can understand the logic of a short timeout - resource usage could spiral out of control.