Dont build commits with the same sha more than once

[drogus]

Sorry for so much of a delay with this, I was doing quite a lot of back & forth with the implementation.

I ended up using postgresql string arrays for keeping branch list for a commit and a build. This by far the best answer in my opinion, because it's dead simple and quite powerful and it does not need getting back to JOINs for getting info on last build on branch etc.

I will also push a small change in the API to start pushing branches as an array (but I will leave branch as an alternative for backwards compatibility).

[drogus]

If no one opposes I'm going to deploy it tomorrow and see how it goes.

[joshk]

Have you tested everything on staging?

[joshk]

Can you also look into the jruby tests not running?

[drogus]

Have you tested everything on staging?

No, I will be doing it tomorrow and if everything works ok I will deploy on production.

Can you also look into the jruby tests not running?

Sure, I will surely do it before deploying

[joshk]

Once you deploy to Staging let me know, I would love to have a play around :)

On 26/06/2013, at 2:14 PM, Piotr Sarnacki notifications@github.com wrote:

Have you tested everything on staging?

No, I will be doing it tomorrow and if everything works ok I will deploy on production.

Can you also look into the jruby tests not running?

Sure, I will surely do it before deploying

—
Reply to this email directly or view it on GitHub.

[drogus]

Sure, I guess I will do it today.

On Wed, Jun 26, 2013 at 3:15 PM, Josh Kalderimis
notifications@github.comwrote:

Once you deploy to Staging let me know, I would love to have a play around
:)

On 26/06/2013, at 2:14 PM, Piotr Sarnacki notifications@github.com
wrote:

Have you tested everything on staging?

No, I will be doing it tomorrow and if everything works ok I will deploy
on production.

Can you also look into the jruby tests not running?

Sure, I will surely do it before deploying

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/223#issuecomment-20045841
.

Piotr Sarnacki
http://piotrsarnacki.com

[drogus]

Sorry for leaving no further comments on this PR. After testing it on staging it turned out that there are problems with plugin which I used for using pg arrays and our jruby apps (travis-hub). I thought that the easiest fix would be to update to rails 4, which has a built-in support for pg arrays, but it turned out to be harder than I thought - although we only use AR, we have a few things, which are problematic. Unfortunately there were other pressing issues at that point and I left this unfinished.

I rebased it to master and I will work on it later this week, especially because of #270 problems.

Things to do:

• - fix pg arrays support, I think it will be better to just use plain SQL for arrays, we will use branches for querying in a few places, so we don't need any fancy plugin for that
• - add the notion of tags to commits, currently they are treated as branches (Don't build tag pushes #270)
• - allow to explicitly opt-in to building branches and/or tags, some of the customers rely on the fact that the build is triggered for each push, even if the push does not contain any new commits. In the future, when builds pipeline is available, we could make more fancy thing, for example if you need to build every commit to upload a build of your library, we could only run a specified stage

[drogus]

This is outdated, so I'm closing it. I will use some parts of this (particularly API changes), but in general most of this PR will be addressed by #320