Unknown branch "master"
maletor opened this issue · comments
I ran setup successfully and there is a post receive hook set up on github.
maletor: Setup organization at git@github.com:organization/project | http://danky.herokuapp.com//organization
hubot ci build organization
comes back with
Unknown branch "master". Push again
No exception. Here's the logs:
2012-02-09T18:02:24+00:00 heroku[router]: POST danky.herokuapp.com/_hubot/organization/master dyno=web.1 queue=0 wait=0ms service=12ms status=404 bytes=35
Using Janky at master.
Janky relies on the Post-Receive hook data to fill in its database. Thing should work properly next time you push to the repository.
I have pushed the branch now and it does not trigger the build on cloudbees. Even though at cloudbees "Notification Plugin" is version 1.3, I see other people have set it up over there so it must work somehow.
Is there any kind of logging information that might be useful here in figuring out why the build isn't triggering.
/cc @sr
seeing the same issue; any resolution?
I worked around this by shortening my commit message and pushing again. The message
column on the commits
table in janky has been defined as a "string" type, which equates to a 255 character max. When github sends the post-receive hook to your janky instance, an exception is triggered:
2012-05-25T13:59:42+00:00 app[web.1]: ERROR: ActiveRecord::StatementInvalid - PG::Error: ERROR: value too long for type character varying(255)
2012-05-25T13:59:42+00:00 app[web.1]: app janky
2012-05-25T13:59:42+00:00 app[web.1]: referrer
2012-05-25T13:59:42+00:00 app[web.1]: method POST
2012-05-25T13:59:42+00:00 app[web.1]: user_agent
2012-05-25T13:59:42+00:00 app[web.1]: : INSERT INTO "commits" ("author", "committed_at", "created_at", "message", "repository_id", "sha1", "updated_at", "url") VALUES ($1, $2, $3, $4, $5, $6, $7, $8) RETURNING "id"
If this commit is the first on the branch, or its the first time you've pushed to this branch, then janky won't create the branch and its an "Unknown branch".
I think this can be fixed by converting the column to a "text" column in a migration in janky.
FYI, this got fixed and pulled in: #74