[CONTROLLER-665] Milestone: autorelease improvements Created: 06/Aug/14 Updated: 19/Oct/17 Resolved: 05/May/15 |
|
| Status: | Resolved |
| Project: | controller |
| Component/s: | adsal |
| Affects Version/s: | Helium |
| Fix Version/s: | None |
| Type: | Improvement | ||
| Reporter: | Ed Warnicke | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: Mac OS |
||
| Description |
|
Note: This is the wrong place for this bug, but we don't have anywhere better right now. Further note this is a placeholder bug to give us something to talk about. We know that we need a number of improvements to autorelease, including: 1) Find a way to get a consistent suffix to replace SNAPSHOT for ODL artifacts in he weeklies so folks can easily consume them. Possible example: foo-x.y.z-SNAPSHOT becomes foo-x.y.z--HELIUM.PRE-vYYYYMMDDMMSS 2) Have the autorelease job dump a simple text file with the tags of the commits its built against as an artifact to the job in a format something like: <gitrepo> <commitid> <buildtag> Example controller 2a7de8c0a2804a981a739ed85a96f190306f47a8 HELIUM.PRE-vYYYYMMDDMMSS So that the projects can build very very simple Jenkins jobs to pull tags. Please don't take the suggestions here as prescriptive, just examples... and more are welcome. 3) Add all of the Helium Projects to autorelease. |
| Comments |
| Comment by Colin Dixon [ 06/Aug/14 ] |
|
I'm going to post two comments. This is the first and I think should be done with or very soon after the 3 things Ed says above. 4.) Provide a script (or other easy to use instructions) that will allow a project to convert all dependencies outside of the project to the latest weekly release. |
| Comment by Colin Dixon [ 06/Aug/14 ] |
|
(In reply to Colin Dixon from comment #1) I should note that this clearly is lower priority than getting the auto-release to work for Helium with all projects such that we can have a fighting chance at releasing Helium on time with minimal pain. |
| Comment by Colin Dixon [ 06/Aug/14 ] |
|
This is my second post. These features are things that I think it would be incredibly handy to have and rely on getting the autorelease working and building weekly releases, but are still related. I think we should have a central place which tracks the current versions for all projects. It seems to me like the odlparent project's pom file would be an ideal place. In this pom file we would have properties defined for every project like: The weekly version would be updated by the weekly run of the auotrelease, presumably by Jenkins pushing a patch back to odlparent. The snapshot would be set by the project itself when they mean to update the version they're exporting to the rest of the world. We could even add versions like: which would be pushed by integration jenkins jobs that make sure the whole of ODL builds and passes system tests with that version. Once you've done this, it makes it pretty easy for projects to pick what version(s) they want to use because they can do so with semantically meaningful strings rather than versions. If done right most projects could just put one like in their pom files that said something like: And then have that be picked up as the default version for every bundle they pull in. As a side note, if you do this, the odlparent project's commits would become something of a universal version number for the whole of OpenDaylight and you would be able to go back and forward in time by just changing how you build the one bundle. |
| Comment by Carol Sanders [ 04/May/15 ] |
|
This bug is part of the project to Move all ADSAL associated component bugs to ADSAL |
| Comment by Tony Tkacik [ 05/May/15 ] |
|
The releng/autorelease project is taking care of this. |