[CXX-1677] Implement tag-based GitHub release workflow Created: 26/Oct/18 Updated: 22/Oct/20 Resolved: 22/Oct/20 |
|
| Status: | Closed |
| Project: | C++ Driver |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Roberto Sanchez | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Epic Link: | Automate C++ driver release process | ||||||||||||||||||||
| Description |
|
Based on a discussion earlier this week, we want to move toward implementation of a release work based on pushing a tag to GitHub. The basic idea is that pushing a release tag (as determined by a designated format) will trigger a full Evergreen build, create all of the distributable artifacts, publish everything to GitHub, and then email the prepared release announcement to the appropriate mail group. A human will review the announcement, confirm that everything is in order, and then send the announcement to the normal places where it is posted publicly. Additional info from jesse (via email): The Evergreen task should actually create the release on GitHub with the release notes and upload the tarball, with code like this: https://github.com/10gen/mongo-c-driver-tools/blob/master/release.py#L493 The script should do everything that can't be undone: it should do everything but send the email to the public mailing lists. |
| Comments |
| Comment by Roberto Sanchez [ 08/Oct/19 ] |
|
john.liu, thanks for the info. After discussing this today within the team, we are going to proceed. Whether the build is triggered by a commit+tag or only a tag, we still need the logic that will perform all the necessary steps in our release process. I can implement all the workings and then later, after the referenced capability exists within Evergreen, we can figure out how to adjust the entrance criteria for the release task to best take advantage of what Evergreen can do. |
| Comment by John Liu (Inactive) [ 08/Oct/19 ] |
|
Please note that PM-1537 will allow you to trigger a build based on the push of a tag, which we are scoping this month and are planning on working on next quarter. If you're willing to wait for that, you won't need to implement a workaround to accomplish this. If you have questions on timelines for that, brian.samek can speak to that |
| Comment by Roberto Sanchez [ 07/Oct/19 ] |
|
So, it looks like at least for now it is not possible to trigger an Evergreen build by pushing only a tag. That is, in order to implement this ticket, our release procedure will require that we push the commit and its associated release tag at the same time. There is an open ticket against Evergeen (EVG-6303) requesting the ability to trigger builds on tags. It is still in the backlog at the moment. |
| Comment by Roberto Sanchez [ 25/Nov/18 ] |
|
In order to start this task in earnest, I think that I need to create a dummy project in GitHub and an associated Evergreen project. I would rather not risk filling up the "real" C++ driver Git repository with with junk commits and tags as I get everything working the way we want. Creating a "dummy" project seems as simple as just forking mongo-cxx-driver. However, what would be the process for connecting my fork to a dummy Evergreen project so that when I push/tag on the fork the dummy Evergreen project gets the notifications? Alternately, if connecting a GitHub repository directly to Evergreen can only be done from within the mongodb organization in GitHub, I would need some help getting in touch with someone who can create an appropriate project to use for working on this task. |