I believe the �Crelease-version2-java-daily was specifically created to support subprojects, so you should use that one.
You can always decide to add new job templates in ci-management if the existing ones don’t fulfill your needs. Thanks, Gary From: 杨艳 [mailto:yangya...@chinamobile.com] Sent: Monday, October 09, 2017 10:42 PM To: Gary Wu <gary.i...@huawei.com> Cc: 'denglingli' <denglin...@chinamobile.com>; onap-discuss@lists.onap.org Subject: 答复: [integration] RE: Questions about independent version and release process Hi Gary， One more question. For some repo, we use release-java-daily not release-version-java-daily job and find these artifacts doesn’t exist in nexus staging repo. And for release-version-java-daily we find it doesn’t support {subproject}. I think there are three options for us : Option1, add release-version-java-daily but the premise is that release-version-java-daily must support {subproject} Option2, don't modify the release-java-daily ,but need the ci-management to add related logic to publish the artifact to staging repo. Option3, I see in global-template-java.yaml there is one template named '{project-name}-{stream}-{subproject}-release-version2-java-daily' , can we use it and wether it can publish artifact to staging repo? We would like to know your suggestion to fix our problem. Best Regards, Yan 发件人: 杨艳 [mailto:yangya...@chinamobile.com] 发送时间: 2017年10月10日 9:57 收件人: 'Gary Wu' 抄送: 'denglingli'; 'onap-discuss@lists.onap.org' 主题: 答复: [integration] RE: Questions about independent version and release process Hi Gary, Thank you for your reply, this is very helpful for us. Best Regards, Yan 发件人: Gary Wu [mailto:gary.i...@huawei.com] 发送时间: 2017年10月10日 1:40 收件人: 杨艳 抄送: 'denglingli'; onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> 主题: [integration] RE: Questions about independent version and release process Hi Yan, 1. If you already have a �Crelease-version-java-daily-no-sonar job, then you don’t need to set up a separate �Crelease-version job. These are just slight variations to the same staging job. 2. The autorelease-xxxx directories are automatically created by the �Crelease-version jobs; you don’t need to perform any manual setup for this. 3. The version numbers (MAJOR.MINOR.PATCH) in the version.properties file needs to correspond to the artifact version that you’re building. For example, if you’re currently building artifact version 1.5.2, then you set your version.properties file to that. Then, separately, you indicate in the version manifest if 1.5.2 is the artifact version you’re delivering for Amsterdam. 4. The “-release-version” jobs only build staging artifacts; it will not build release artifacts. To make a specific staging artifact into a release artifact, email LF helpdesk. 5. Strictly speaking, it’s up to you which branch you want to use to build artifacts for which versions. In practice, I think all projects are currently doing development on the master branch, so you should modify the pom file in the master branch to inherit from the release version of oparent. You do not need to use special tags for dependencies on oparent. Thanks, Gary From: 杨艳 [mailto:yangya...@chinamobile.com] Sent: Monday, October 09, 2017 1:42 AM To: Gary Wu <gary.i...@huawei.com<mailto:gary.i...@huawei.com>> Cc: 'denglingli' <denglin...@chinamobile.com<mailto:denglin...@chinamobile.com>> Subject: Questions about independent version and release process Hi Gary, For the Independent Versioning and Release Process<https://wiki.onap.org/display/DW/Independent+Versioning+and+Release+Process>, We didn’t know very clearly the process and want to confirm several issues with you. As my understanding, we should follow the following steps to release our components artifacts, if I am wrong ,please correct me. 1. We should set up �Crelease-version jobs for each components We want to know should we set up another �Crelease-version jobs or it is same as -release-version-java-daily-no-sonar<https://jenkins.onap.org/view/vfc/job/vfc-gvnfm-vnflcm-master-release-version-java-daily-no-sonar/> and release-java-daily? In the wiki page this step have two description * Generates candidate “autorelease-xxxx” directories in Nexus --- Do we need to create the directory in each repo? * Ensure that your version.properties file has the right version number defined for the intended release. --- the vesion number here must be consistent with the release number, is it right If we add the Jenkins job for each components,it will generate the release artifact in releases repo automatically or not? Because we inherit from onap-oparent, how do we need to deal with this dependency, should we modify the pom file to inherit the release onap-oparent aritifact in master branch or should we create another tag in gerrit? If it isn’t right, can you help to clarify the right process. 2. Email helpd...@onap.org<mailto:helpd...@onap.org> to select a candidate as formal release artifact 3. Update the declared version numbers for your respective artifacts in the java version manifest 4. When should we bump your own version numbers for ongoing development, we haven’t see the release branch in gerrit? Best Regards， Yan
_______________________________________________ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
