[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:
Depends
depends on CXX-1903 Retrieve release notes from Jira via ... Closed
is depended on by CDRIVER-2845 Improve C driver release process Closed
Duplicate
is duplicated by CXX-2100 Automate Driver Releases Closed
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 ]

kevin.albertson, jesse,

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.

Generated at Wed Feb 07 22:03:33 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.