>Another possibility is that we leave the PBK's where they are and simply add >new build targets to flex-sdk build script. That might be simpler and gives >us the option of >reverting back to a single package if we find that we can >someday.
That sound like a good idea. I think the build script should be a concatenation of the current pixel_bender_compile (that produces the pbj in place) and "archive-pbj" target in the main build.xml, that zips the sdk pbjs, in ./out/pb.tar. Someone would run this script once, then commit the zip file to flex-utilities/pixel_bender, that could be used by other scripts... WDYT? Maurice -----Message d'origine----- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : jeudi 12 décembre 2013 19:06 À : dev@flex.apache.org Objet : Re: PixelBender and Builds.a.o Another possibility is that we leave the PBK's where they are and simply add new build targets to flex-sdk build script. That might be simpler and gives us the option of reverting back to a single package if we find that we can someday. -Alex On 12/12/13 9:55 AM, "Alex Harui" <aha...@adobe.com> wrote: >I was going to move (not copy) the pbks out to flex-utilities. Today >we already pull in source from flex-tlf repo when making a release package. >I think it will work if I do essentially the same thing for the pbks. > >-Alex > >On 12/12/13 9:42 AM, "Maurice Amsellem" <maurice.amsel...@systar.com> >wrote: > >>>IMO, the binary package can only contain pbj's if the source package >>>contains the source pbk's and a way to compile them. >>>The binary package probably cannot contain >a zip of the pbj's either. >>>The idea of the binary package is that it contains the result of the >>>compilation, to save folks >having to set up the compile/build >>>environment. >My understanding is that it cannot contain other >>>artifacts. >> >>You are correct. >>So does this mean the pbk would be duplicated on both dist repo and >>flex-sdk git repo? >>I don't like the idea to have duplicate source code. >> >>Otherwise, this means the pbk would be in one single place, so >>necessarily in flex-sdk git repo (as is currently the case). >>This implies the build file in dist would fetch the pbk sources from >>git, which means cloning the whole git flex-sdk repo for 10 source files... >> >>So it's git clone for 10 files, or duplicate source, but for files >>that won't change much. >> >>WDYT? >> >>Maurice >> >>-----Message d'origine----- >>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : jeudi 12 décembre >>2013 18:20 À : dev@flex.apache.org Objet : Re: PixelBender and >>Builds.a.o >> >> >> >>On 12/12/13 9:00 AM, "Maurice Amsellem" <maurice.amsel...@systar.com> >>wrote: >> >>>> 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 ? >>Ah, I understand now. Yes, we use SVN to put things on dist. We >>didn't used to. When you say svn or git I think of our repos. Dist >>(and >>archive) can have binary artifacts. >>> >>>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 .. >>IMO, the binary package can only contain pbj's if the source package >>contains the source pbk's and a way to compile them. The binary >>package probably cannot contain a zip of the pbj's either. The idea >>of the binary package is that it contains the result of the >>compilation, to save folks having to set up the compile/build >>environment. My understanding is that it cannot contain other artifacts. >> >>> >>>>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 >>>> >>> >> >
