You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Matt Stephenson <ma...@mattstep.net> on 2013/06/25 21:24:28 UTC

Please do not ignore build failures

If cloudbees or dev@cloud fails your pull request, please do not merge it
in.  Please determine the root cause or try to reach out to those that
might know.

Matt

Re: Please do not ignore build failures

Posted by Everett Toews <ev...@RACKSPACE.COM>.
Yep. The build for jclouds.github.com is broken. 

Looks like it's dying on

  + /home/jenkins/.gem/ruby/1.9.1/gems/jekyll-1.0.3/bin/jekyll --no-lsi --safe

  Deprecation: Jekyll now uses subcommands instead of just switches. Run `jekyll help' to find out more.

  invalid option: --no-lsi

Also deploy-site.sh still doesn't work for me.

  ...
  G    site-content/index.html
  G    site-content/news/index.html
  Updated to revision 1496598. 
  svn: warning: '{}' not found
  svn: warning: ';' not found
  A         documentation/releasenotes/1.6.1
  A         documentation/releasenotes/1.6.1/index.html
  Sending        documentation/devguides/creating-providers-with-maven/index.html
  svn: Commit failed (details follow):
  svn: access to '/repos/asf/!svn/ver/1492807/incubator/jclouds/site-content/documentation/devguides/creating-providers-with-maven/index.html' forbidden

I've been trying to get the release notes published for almost two days now and it's truly starting to affect my sanity. 8)

Everett


On Jun 25, 2013, at 2:24 PM, Matt Stephenson wrote:

> If cloudbees or dev@cloud fails your pull request, please do not merge it
> in.  Please determine the root cause or try to reach out to those that
> might know.
> 
> Matt

Re: Please do not ignore build failures

Posted by Everett Toews <ev...@RACKSPACE.COM>.
My bad. My frustration and impatience got the better of me. Lesson learned.

It turns out I do have access to the jclouds.github.com<http://jclouds.github.com> BuildHive. I signed in with my GitHub account so maybe it's a function of my GitHub permissions. Everyone should go to the jclouds.github.com<http://jclouds.github.com> config page [1] and see if they can access it. If not, we should fix the permissions so all committers can.

I fixed the BuildHive error due to the backwards incompatible change and fixed a deprecation warning too. The build is passing successfully now.

I'm still unable to use deploy-site.sh and it appears to be an Apache permissions problem. I'll file an issue with INFRA and see if they can help.

Thanks,
Everett

[1] https://buildhive.cloudbees.com/job/jclouds/job/jclouds.github.com/configure

On Jun 25, 2013, at 3:26 PM, Matt Stephenson wrote:

Jekyll made some backwards incompatible changes it looks.

Regardless, in the future please notify people when you notice the build is
failing and it doesn't appear to be your change in particular.  I generally
ignore when it fails if it's not my pull request, if it's my pull request I
always make sure it's clean.  Even if it blocks merging it in before fixing
something in cloudbees.


On Tue, Jun 25, 2013 at 1:00 PM, Everett Toews
<ev...@rackspace.com>>wrote:

On Jun 25, 2013, at 2:36 PM, Andrew Phillips wrote:

Could someone with access to the BuildHive job configuration take a look?


All committers should have access to all BuildHive jobs. When we run into
problems like these we should not have to block on someone with access. We
all need the ability to fix these changes. We are all responsible for
documentation and it's build process.

Can the owner of the jclouds.github.com<http://jclouds.github.com> BuildHive please give all of us
access to these jobs?

Everett

Re: Please do not ignore build failures

Posted by Matt Stephenson <ma...@mattstep.net>.
Jekyll made some backwards incompatible changes it looks.

Regardless, in the future please notify people when you notice the build is
failing and it doesn't appear to be your change in particular.  I generally
ignore when it fails if it's not my pull request, if it's my pull request I
always make sure it's clean.  Even if it blocks merging it in before fixing
something in cloudbees.


On Tue, Jun 25, 2013 at 1:00 PM, Everett Toews
<ev...@rackspace.com>wrote:

> On Jun 25, 2013, at 2:36 PM, Andrew Phillips wrote:
>
> > Could someone with access to the BuildHive job configuration take a look?
>
>
> All committers should have access to all BuildHive jobs. When we run into
> problems like these we should not have to block on someone with access. We
> all need the ability to fix these changes. We are all responsible for
> documentation and it's build process.
>
> Can the owner of the jclouds.github.com BuildHive please give all of us
> access to these jobs?
>
> Everett

Re: Please do not ignore build failures

Posted by Everett Toews <ev...@RACKSPACE.COM>.
On Jun 25, 2013, at 2:36 PM, Andrew Phillips wrote:

> Could someone with access to the BuildHive job configuration take a look?


All committers should have access to all BuildHive jobs. When we run into problems like these we should not have to block on someone with access. We all need the ability to fix these changes. We are all responsible for documentation and it's build process.

Can the owner of the jclouds.github.com BuildHive please give all of us access to these jobs?

Everett

Re: Please do not ignore build failures

Posted by Andrew Phillips <ap...@qrmedia.com>.
> If cloudbees or dev@cloud fails your pull request, please do not merge it
> in.  Please determine the root cause or try to reach out to those that
> might know.

+1. If we're talking about the BuildHive failure for the recent site  
update, this actually appears to be related to changes in jekyll:

>        Deprecation: Jekyll now uses subcommands instead of just  
> switches. Run `jekyll help' to find out more.
> invalid option: --no-lsi

Could someone with access to the BuildHive job configuration take a look?

Thanks!

ap