flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Thayne <s...@skyseek.com>
Subject Re: [Builds/Jenkins] Help and advise needed
Date Tue, 10 Dec 2013 19:25:36 GMT
I'd really suggest you guys move to Bamboo. It connects to Jira for user
access control. You can easily set admin rights for specific users. It's
remote agents are way better than jenkin slaves.

I use it for compiling ANEs, Air apps and SWFs. Super easy to setup.

Another great benefit is you can easily have it create/test separate
branches.

Like Jira it's free for open source projects. And their main team of
developers are super responsive and always looking for and open to new
ideas/changes.

~Sean

<http://www.skyseek.com>
class *Sean_Thayne*
    extends Developer {
        public $skype = "sthayne23";
        public $gTalk = "sean@skyseek.com";
        public $url   = "www.skyseek.com";
}


On Tue, Dec 10, 2013 at 12:12 PM, Maurice Amsellem <
maurice.amsellem@systar.com> wrote:

> There is a utility in pixel bender toolkit directory called
> "sniffer_gpu.exe" that check the presence and version of OpenGL:
>
> Console output on my laptop is below:
>
> C:\Program Files (x86)\Adobe\Adobe Utilities - CS5\Pixel Bender Toolkit
> 2>sniffer_gpu.exe
> Device: 0058A9F4 has video RAM(MB): 512
> Vendor string:    NVIDIA Corporation
> Renderer string:  NVS 4200M/PCI/SSE2
> Version string:   3.0.0
>
> OpenGL version as determined by Extensionator...
> OpenGL Version 3.0
> Has NPOT support: TRUE
> Has Framebuffer Obeject Extension support: TRUE
> Completed shader test!
> Return code: 7
>
> Maybe we could temporarily modify the build to run this utility and show
> the output on the b.a.o vm.
>
> WDYT ?
>
> Maurice
>
> -----Message d'origine-----
> De : Alex Harui [mailto:aharui@adobe.com]
> Envoyé : mardi 10 décembre 2013 18:15
> À : dev@flex.apache.org
> Objet : Re: [Builds/Jenkins] Help and advise needed
>
> I don't think we actually know the cause of the problem.  I am going to
> continue to spend cycles to try to find out though.
>
> It would be nice to have an alternative to builds.a.o.  I'm not sure if it
> will cost Om money to run a builds server.
>
> -Alex
>
> On 12/10/13 2:01 AM, "Maurice Amsellem" <maurice.amsellem@systar.com>
> wrote:
>
> >I understand that.
> >
> >Actually, my "understanding" on this issue was that pixel bender
> >compiler required some sort of hardware configuration (OpenGL, etc...)
> >that were not present on the b.a.o. new Windows Jenkins slave node, so
> >that's why the build was failing,  and the Apache Infra was reluctant
> >to let us modify anything, or even access the VM ourselves.
> >So that's why I was proposing a "software only" solution.
> >
> >Now, it seems from what Om is saying that we can set up and use our own
> >Jenkins slave node VM.
> >
> >That, of course, is much preferable...
> >
> >Maurice
> >
> >-----Message d'origine-----
> >De : Erik de Bruin [mailto:erik@ixsoftware.nl] Envoyé : mardi 10
> >décembre 2013 10:44 À : dev@flex.apache.org Objet : Re:
> >[Builds/Jenkins] Help and advise needed
> >
> >Maurice,
> >
> >Your help is very much appreciated!
> >
> >I put "legal" in quotes, the issue is not really one of the law, more
> >of the rules. An Apache release is supposed to be 'source only', and we
> >if we can produce needed binaries from source, we keep only the source,
> >not the artefacts themselves in the repo.
> >
> >
> >EdB
> >
> >
> >
> >On Tue, Dec 10, 2013 at 10:34 AM, Maurice Amsellem
> ><maurice.amsellem@systar.com> wrote:
> >>>In addition to the various "legal" issues with binaries in the repo.
> >> I understand it's not a good idea to have binaries in the repo, so I
> >>won't insist.
> >> But please can you explain what are the legal issues of having
> >>binaries in the repo?  Is this because of Adobe, or ASF rules ?
> >>
> >> On a side note, I was just trying to help, with my limited
> >> understanding and knowledge, and because the email thread was titled
> >> "help and advise needed" ;-)
> >>
> >> Regards,
> >>
> >> Maurice
> >>
> >> -----Message d'origine-----
> >> De : Erik de Bruin [mailto:erik@ixsoftware.nl] Envoyé : mardi 10
> >> décembre 2013 09:12 À : dev@flex.apache.org Objet : Re:
> >> [Builds/Jenkins] Help and advise needed
> >>
> >> In addition to the various "legal" issues with binaries in the repo,
> >>we'd be masking the cause of this failure. In order to prevent further
> >>deterioration of the build process, we need to figure out what went
> >>wrong and fix it.
> >>
> >> EdB
> >>
> >> PS. Thanks for leaving the keyboard on the Mustella VM set to FR...
> >> Took me while to figure out that I hadn't gone insane or if my
> >> keyboard was broken ;-)
> >>
> >>
> >>
> >> On Tue, Dec 10, 2013 at 9:04 AM, Maurice Amsellem
> >><maurice.amsellem@systar.com> wrote:
> >>>> someone who does use the pbj's will grab the nightly and complain.
> >>>
> >>> I don't understand.
> >>> Why would someone complain if the pbj's are in the nightly?
> >>>
> >>> [From the other emai]
> >>>>Apache repos aren't supposed to contain compiled code.  The pbj
> >>>>files were removed during the initial release audit.
> >>>>I don't think a workaround can involve checking in the pbj files.
> >>>>But we could borrow them from a prior release package temporarily.
> >>>
> >>>>So we could make the compilation conditional on a env parameter,
> >>>>and set that in the Jenkins job accordingly?
> >>>>Yes but ...
> >>>
> >>> Alex, the conversation is getting out synch, so I am not sure that I
> >>>have understood what you said.
> >>>
> >>> So can we include the pbj in the repo, and have a parameter to
> >>>conditionally compile the pbj ?
> >>> - This parameter would be set by default to do the compilation (so
> >>>that folks can recompile)
> >>> - and turned off on the b.a.o vm, with pre-compiled pbj's.
> >>>
> >>>
> >>> Maurice
> >>>
> >>
> >>
> >>
> >> --
> >> Ix Multimedia Software
> >>
> >> Jan Luykenstraat 27
> >> 3521 VB Utrecht
> >>
> >> T. 06-51952295
> >> I. www.ixsoftware.nl
> >
> >
> >
> >--
> >Ix Multimedia Software
> >
> >Jan Luykenstraat 27
> >3521 VB Utrecht
> >
> >T. 06-51952295
> >I. www.ixsoftware.nl
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message