+ Naming convention for build jobs devstudio-tooling-esb, devstudio-tooling-platform and so on, i.e same as the repo name.
On Tue, Feb 7, 2017 at 11:44 PM, Susinda Perera <[email protected]> wrote: > Hi All > I'm thinking of subject as I found some difficulties when trying to > release a product tooling. Note that we have following repos[1]. > Currently we have to set following parameters to trigger a build > 1. Release_Type - Product Release or Update Release > 2. kernel_version - eg 4.1.0, 4.2.0 or etc > 3. Product_code - eg platform, esb, dss, apim, ei and so on > 4. Features_List - All > 5. Name of the release branch - eg master > 6. Releasing_version - Name of your release eg RC2 , Beta > 7. Tag - Create a tag - true/false > 8. Publish_into_staging_p2 - Publish p2 into staging p2 repository - > true/false > 9. Publish_main_p2 - Create composite p2 repository - true/false > 10. Publish_composite_p2 - Create composite p2 repository (Product plugin > + Platform Plugin + Kernel plugins) - true/false > 11. Publish_Installed_Distribuntions - Create Installed distributions > (composite + eclipse) - true/false > > I'm suggesting to use only the params 5,10,11,7 and 8 on same order. Let > me explain why we do not want other params > 1 - For update releases, we see that(from the updates released so far) we > have released the entire repo (have no other option as well), not a > particular feature only. And also eclipse p2 installer takes care of > installing only the updated components, so it does not matter if we release > the entire repo even we have a fix in only one component. So we can go > with Release_Type=='Product Release' in all the times. Also 4. Feature_List > param is broken, is seems it only works for one feature, cannot use 'All' > or comma separated names of features. Therefore we can omit the parameter 1 > and 4. > 2 - Kernel version is already defined in the pom and MANIFEST.MF when > declaring dependencies > 3 - For a particular repo eg devstudio-tooling-ei we don't want to specify > the product code again as 'ei' as its redundant > 4 - Discussed in 1. above - We do not want this if we go for > Release_Type=='Product Release' always > 6 - Releasing version - This can be derived from pom > 9 - Simplest build is the building main-p2, so we can have this as the > default for all builds, Additional builds may contain composite p2 or > installed disttributions > > Once the build is success with param 9, or (9 and 10) or (9 and 10 and 11) > then we can create a tag and publish into staging p2. Hence 7. and 8. > params are placed at the end. > > Also id like to suggest following rules for build. > Continuous build has to be configured with master branch - It may or may > not use 10 and 11 -TBD > For releases - A branch has to be created and branch name should be in > following format - <version>-release - eg 4.1.1-release > Once released, build job should create a tag in github with his format > <version>-release-$GIT_TAG_SAFE_BUILD_TIMESTAMP eg - > 4.1.1-release-2017-02-07-233842 > For updates - A branch need to be created and should be of following > format - <version>-update-N - eg 4.1.1-update-1, 4.1.1-update-2, > 4.1.1-update-3 etc > Once update build is success build job should create a tag in following > format - <version>-update-N-$GIT_TAG_SAFE_BUILD_TIMESTAMP, eg > 4.1.1-update-3-2017-02-07-233842 > > *Summary* > we may use following params > 1. Name of release branch - eg 4.1.1-release > 2. Publish_composite_p2 > 3. Publish_Installed_Distribuntions > 4. Tag > 5. Publish_into_staging_p2 > Branch names for releases and updates has to use following naming pattern > 4.1.1-release or 4.1.1-update-3 > Tag names should have similar pattern with $GIT_TAG_SAFE_BUILD_TIMESTAMP > appended by the build job > > Note that this is just few ideas came to my mind for $subject. I might > have missed some use cases or this might not work, Therefore please share > your thoughts and good if we can have a discussion on this. > > [1] - Repo List > https://github.com/wso2?utf8=%E2%9C%93&q=devstudio-tooling&type=&language= > > Thanks > Susinda > > > -- > *Susinda Perera* > Software Engineer > B.Sc.(Eng), M.Sc(Computer Science), AMIE(SL) > Mobile:(+94)716049075 > Blog: susinda.blogspot.com > WSO2 Inc. http://wso2.com/ > Tel : 94 11 214 5345 Fax :94 11 2145300 > > -- *Susinda Perera* Software Engineer B.Sc.(Eng), M.Sc(Computer Science), AMIE(SL) Mobile:(+94)716049075 Blog: susinda.blogspot.com WSO2 Inc. http://wso2.com/ Tel : 94 11 214 5345 Fax :94 11 2145300
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
