[MONGOCRYPT-81] Publish libmongocrypt .so/.dll artifacts in known locations Created: 17/May/19  Updated: 28/Oct/23  Resolved: 24/May/19

Status: Closed
Project: Libmongocrypt
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Roberto Sanchez Assignee: Roberto Sanchez
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Epic Link: Build libmongocrypt library

 Description   

When libmongocrypt is built in Evergreen, a task for each architecture and platform must publish libmongocrypt.so or mongocrypt.dll (as appropriate) to a known location. This will allow the Java driver to retrieve the binary artifacts for its own publication process. Publication of the artifacts should only be for non-patch builds and, in the absence of a concrete tag-based versioning scheme, should use a path/directory based on the Git commit ID from which the build was created.

CC: kevin.albertson samantha.ritter jeff.yemin ian.whalen



 Comments   
Comment by Githook User [ 24/May/19 ]

Author:

{'name': 'Roberto C. Sánchez', 'email': 'roberto@connexer.com', 'username': 'rcsanchez97'}

Message: CDRIVER-3133 publish shared library artifacts in known locations
Branch: master
https://github.com/10gen/libmongocrypt/commit/08e8571882b34a85fcf0d3842be00bf336bff0db

Comment by Jeffrey Yemin [ 20/May/19 ]

I think we should prefix "latest" with the branch name:

https://s3.amazonaws.com/mciuploads/libmongocrypt/ubuntu1604/master/latest/libmongocrypt.tar.gz
https://s3.amazonaws.com/mciuploads/libmongocrypt/ubuntu1604/1.0.x/latest/libmongocrypt.tar.gz

So we can have one per branch. This will allow Java build to find the correct "latest" build for each snapshot build. Though I imagine we could use the commit hash instead for that.

What do you think, ross.lawley?

Comment by Roberto Sanchez [ 18/May/19 ]

That sounds good.

Comment by Kevin Albertson [ 18/May/19 ]

Right now we have a super simple scheme. Each variant has a task that uploads to one "latest" location (example).

https://s3.amazonaws.com/mciuploads/libmongocrypt/ubuntu1604/latest/libmongocrypt.tar.gz

For a patch build, we also identify with the task name and revision ID:

https://s3.amazonaws.com/mciuploads/libmongocrypt/ubuntu1604/5a698e0dc6d2dd7c6a865941188e77b8626bb91e/build-and-test-and-upload/libmongocrypt_ubuntu1604_patch_5a698e0dc6d2dd7c6a865941188e77b8626bb91e_5ce021a33066150816b7ed8f_19_05_18_15_15_47/libmongocrypt.tar.gz

So, I imagine we'll keep patch builds the same. And as you describe, a non-patch, non-release builds gets identified by commit hash, like:

https://s3.amazonaws.com/mciuploads/libmongocrypt/ubuntu1604/<commit hash>/libmongocrypt.tar.gz

And on release commit, identify with the git tag (I don't think hash is unnecessary since we shouldn't be moving tags around):

https://s3.amazonaws.com/mciuploads/libmongocrypt/ubuntu1604/<git tag>/libmongocrypt.tar.gz

Should we keep the "latest" URL for all non-patch builds, and possibly repurpose that to the latest tagged release?

Comment by Roberto Sanchez [ 17/May/19 ]

My intended approach is to publish for every non-patch Evergreen build (i.e,. whenever a push is made to GitHub), using the Git commit ID as the identifier for the publication. After tagging is in place, we can keep this behavior and publish using any identified tag(s) instead of (or in addition to) the Git commit ID. That should allow for depending on any arbitrary libmongocrypt artifact so long as you know the commit ID from which it was built.

Comment by Jeffrey Yemin [ 17/May/19 ]

We need to also publish something for non-releases so that the bindings can create pre-releases (SNAPSHOTs in Maven parlance)

Comment by Roberto Sanchez [ 17/May/19 ]

Good point. However, we do not yet have such a scheme. For this ticket I can implement the publication based on the Git commit hash, then once we have a tagging strategy implemented, it can be updated to take advantage of that. Perhaps it may even only publish when building on a release tag.

Comment by Jeffrey Yemin [ 17/May/19 ]

What do you mean by "in absence of a concrete tag-based versioning scheme"? I assume that's exactly what we are going to have, like I imagine the C driver does.

Generated at Thu Feb 08 09:07:55 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.