>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 >> >
