Hi Brett, we don't use the Jenkins Artifactory plugin but we follow a similar staging process. What we've ended up doing is
* just number/label every build the same way (i.e., no special "rc1" labels); * get the incrementing version number from the Jenkins build number, rather than from a file in source control; * only promote the ones which pass appropriate testing; * tag source control for fully-promoted builds, using source revision info from Jenkins or from files stored in the published artifacts. We never re-publish a build when it's promoted, which also means all our ivy.xml files always have "release" status, rather than us initially publishing them with "integration" and then changing it when we promote. That also makes caching more straightforward on the client side. Knowledge of what is a release candidate or not is external to Jenkins and Artifactory, though I suppose Artifactory metadata properties would be a reasonable place to put a temporary "this is just a candidate for now" flag. Hope that helps, Hugh Greene, Senior Software Developer Toshiba Medical Visualization Systems Europe, Ltd Bonnington Bond, 2 Anderson Place, Edinburgh EH6 5NP, UK Tel + 44 (0)131 472 4792 / Fax + 44 (0) 131 472 4799 http://www.tmvse.com / mailto:[email protected] DISCLAIMER Unless indicated otherwise, the information contained in this message is privileged and confidential, and is intended only for the use of the addressee(s) named above and others who have been specifically authorized to receive it. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message and/or attachments is strictly prohibited. The company accepts no liability for any damage caused by any virus transmitted by this email. Furthermore, the company does not warrant a proper and complete transmission of this information, nor does it accept liability for any delays. If you have received this message in error, please contact the sender and delete the message. -----Original Message----- From: Brett Cashman [mailto:[email protected]] Sent: 18 December 2015 21:43 To: [email protected] Subject: [Artifactory-users] Jenkins + Gradle + Artifactory: Help w/ release staging I’m using a Jenkins instance to execute Gradle builds and publish distribution snapshots to Artifactory via the Jenkins Artifactory plugin. This all works swimmingly, and I’d like to expand our use case to include the release staging functionality (we have Artifactory Pro). However, I’m having difficulty wrapping my head around the intended workflow. As I understand it: When we’re close to a delivery date, we “stage” a release. This involves (a) specifying the release version number and cutting a new build, which then gets published into some intermediate, staging repository, and (b) specifying the next development version number, which gets committed back into the source branch. The “staged” release amounts to a release candidate. The idea is that it should get focused testing, and, if all goes well, it gets “promoted” — essentially copied — from the intermediate, staging repository into a release repository from which it can be grabbed for use in production environments. Where I’m struggling with this is understanding the intended workflow for the much-more-common case where testing of the RC doesn’t go well, and we have to accept a few changes and cut another RC. The staging plugin allows for a “roll back” status, but this only affects the artifact metadata in Artifactory; it doesn’t, for example, reverse the commit to the source branch incrementing the next development version number. Moreover, if we re-use the same version number for the “new” RC, then the previous RC will get overwritten unless we move it out of the staging repo; but if we don’t — for example, if we identify our RCs by calling them “rc1”, “rc2”, etc. — then that extraneous information will stay in the RC name and in the generated poms when we eventually promote it to a release. Can some kind soul provide some guidance, here? Thanks, -Brett ------------------------------------------------------------------------------ _______________________________________________ Artifactory-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/artifactory-users ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ ------------------------------------------------------------------------------ _______________________________________________ Artifactory-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/artifactory-users
