[SERVER-29422] Respect version.json in Evergreen patch builds Created: 02/Jun/17 Updated: 30/Oct/23 Resolved: 15/Aug/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Build |
| Affects Version/s: | None |
| Fix Version/s: | 3.5.12 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Michael Cahill (Inactive) | Assignee: | Brian Samek |
| Resolution: | Fixed | Votes: | 2 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Backport Requested: |
v3.4, v3.2
|
||||||||||||
| Sprint: | Evergreen 2017-08-15 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
To create a patch build that can be deployed with Ops Manager, it is currently necessary to update both etc/evergreen.yml to include a custom version string and create a version.json file to set the githash, which repeats (hopefully) the version string. See this patch build for an example. I propose that we make the change ramon.fernandez suggested in Something like:
|
| Comments |
| Comment by Githook User [ 15/Aug/17 ] |
|
Author: {'username': 'bsamek', 'email': 'brian.samek@mongodb.com', 'name': 'Brian Samek'}Message: |
| Comment by Andrew Morrow (Inactive) [ 03/Jun/17 ] |
|
I have a slightly different proposal. I think we should stop using the scons MONGO_VERSION= form in etc/evergreen.yml entirely. The fact that we re-iterate the git-describe logic there is unfortunate. SCons will already honor any version.json file, unless values are overridden on the command line, and will fall back go git-describe if neither of the above mechanisms are in play. So, if we stop setting MONGO_VERSION on the command line, adding a version.json file to your patch will just do the right thing. In the event that evergreen is running a patch build, and that patch doesn't contain a version.json file, then we can write one which injects the \${version_id} of the patch, achieving the desired effect. Though, much as ramon.fernandez says, we could always move forward with michael.cahill's suggestion for now and then migrate to this solution later. |