[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: | ||||
| Comment by Jeffrey Yemin [ 20/May/19 ] | ||||
|
I think we should prefix "latest" with the branch name:
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).
For a patch build, we also identify with the task name and revision ID:
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:
And on release commit, identify with the git tag (I don't think hash is unnecessary since we shouldn't be moving tags around):
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. |