> B) I don't think I understood your 4a, but it doesn't sound like it would > meet policy. No zips are allowed in svn.
I am confused. Isn't https://dist.apache.org/repos/dist/dev/flex/sdk/4.11.0/rc1/binaries/ an svn repo? And it does contain zip and binaries. So if svn cannot contain zips, how do we make commit the result of pb compilation ? as plain files ? My 4a) is more or less your B) => "build scripts copy the pbk source from dist into the source package and pbjs from dist into the binary package". Expect that I retrieve one zip file with internal directory structure (same as the one produced by obsolete pixel_bender Jenkins job) from dist and copy it to binary package, instead of individual flat files. I don't think this breaks any rule .. >If you plan to take this on, please let us know Not at the moment. I am just trying to detail the steps, in case it needs to be done later (by anyone who want to). Hoping the infra will fix the current issue... Maurice -----Message d'origine----- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : jeudi 12 décembre 2013 17:44 À : dev@flex.apache.org Objet : Re: PixelBender and Builds.a.o I agree with most of it except: A) we can't auto-commit to dist. I believe only voted on artifacts can go there. But realistically, I think we're only going to commit once unless someone find a reason to change the PBK files. B) I don't think I understood your 4a, but it doesn't sound like it would meet policy. No zips are allowed in svn. A binary package is only supposed to additionally contain compiled artifacts of the source package. I'd rather not have to change the installer either right now since I'm working on a major upgrade to it and don't want to add that to the delays to get our CI up and running again. I think the best short term answer is that the SDK build scripts copy the pbk source from dist into the source package and pbjs from dist into the binary package. That sort of fudges the tag==package policy but essentially we can show there are already multiple tags in our packages since we pull TLF from its own repo. If you plan to take this on, please let us know. I'm waiting to see if Infra did try again to reboot the server. If they did and the recent failure means it is still busted, it is definitely time to start making these changes, so one of should start on it. -Alex On 12/12/13 8:27 AM, "Maurice Amsellem" <maurice.amsel...@systar.com> wrote: >Thanks Alex. > >So IIUC, > >1) create new folder "pixel_bender" under >https://dist.apache.org/repos/dist/dev/flex/ SVN repo > - will contain the zip files generated by the build below > >2) add new project " flex-sdk_pixelbender" in "flex-utilities" GIT repo >containing: > - PBK sources for flex-sdk > - build file for compiling pbk into pbj > Output = pb.zip file containing pbj + pbk (similar structure to >current pixelbender upstream Jenkins job) > [Bonus] auto-commmit the zip file to >dist/.../pixel_bender > >=> build file must be run manually by "Release manager" > >3) remove flex-sdk_pixelbender upstream job from b.a.o Jenkins >(obsolete) > >4) to include pbk+pbj in Flex SDK release there are two options >a) modify build_release.sh (or equivalent) to checkout pb.zip from svn >and unzip into dist >b) add checkout+checkMD5+unzip step in flex sdk installer > >Is that correct? >What option in 4) I think a) is the easiest, and it does not break any >Apache rule. > >Maurice > >-----Message d'origine----- >De : Alex Harui [mailto:aha...@adobe.com] Envoyé : jeudi 12 décembre >2013 15:40 À : dev@flex.apache.org Objet : Re: PixelBender and >Builds.a.o > > > >On 12/12/13 5:03 AM, "Maurice Amsellem" <maurice.amsel...@systar.com> >wrote: > >>I am trying to understand the steps below: >> >>Where would the pbk => pbj compilation take place ? >In the build script for this "project". >> >>Where would the pbj be stored after the build , if the build does not >>occur on the CI? >On the same servers we store our voted on releases. >>Will the pbj be compiled by Jenkins ? or built manually and stored >>somewhere ? >All releases are compiled by someone running the build script and >signing the artifacts. Apache even seems to not want to allow signing >of Jenkins-built artifacts. > >-Alex >
