For first pass, I propose just going with the MVP of allowing CI to re-build code as production regardless what we have snapshots built as and then tackle needs as we go. See the end of this ticket for more reasoning.
Scope
This ticket really covers CI's responsibility of automating the publication, etc (responding to the trigger, providing visibility into the results) vs the publication itself (meat of this is covered in another ticket).
Generation, inclusion, and normalization of build metadata being embedded in build output (touched on below) is captured in a different ticket.
Approach - Versioning
Versioning will be semantic and not swayed by marketing or business objectives. It's meant to be human informed, but machine consumed.
Versions will be determined dynamically by the last present git tag in VCS + whatever bump is indicated by the human kicking it off (single bumps to major, minor, or patch versions).
Other metadata that might be useful for testing or other development activities will be embedded in the resulting artifacts (flat file, jars, whatever is published and/or handed around during development).
Approach - CI Glue
Use a combo of webhooks and drone.io plugins.
Artifactory pro oss cloud will allow us to promote artifacts to release artifacts (which would mean we'd have to build snapshots as production code). While this ensures there is no way for any new code or problems to leak their way into the release, it's not available in their OSS self-hosting and I doubt we'll pay for pro cloud.
Therefore, I'd like to not rely on Artifactory pro abilities. We should roll our own solution to promoting snapshot binaries or just allow CI to re-build it as a production binary. Each approach has tradeoffs.
For first pass, I propose just going with the MVP of allowing CI to re-build code as production regardless what we have snapshots built as and then tackle needs as we go. See the end of this ticket for more reasoning.
Scope
This ticket really covers CI's responsibility of automating the publication, etc (responding to the trigger, providing visibility into the results) vs the publication itself (meat of this is covered in another ticket).
Generation, inclusion, and normalization of build metadata being embedded in build output (touched on below) is captured in a different ticket.
Approach - Versioning
Versioning will be semantic and not swayed by marketing or business objectives. It's meant to be human informed, but machine consumed.
Versions will be determined dynamically by the last present git tag in VCS + whatever bump is indicated by the human kicking it off (single bumps to major, minor, or patch versions).
Other metadata that might be useful for testing or other development activities will be embedded in the resulting artifacts (flat file, jars, whatever is published and/or handed around during development).
Approach - CI Glue
Use a combo of webhooks and drone.io plugins.
Artifactory pro oss cloud will allow us to promote artifacts to release artifacts (which would mean we'd have to build snapshots as production code). While this ensures there is no way for any new code or problems to leak their way into the release, it's not available in their OSS self-hosting and I doubt we'll pay for pro cloud.
Therefore, I'd like to not rely on Artifactory pro abilities. We should roll our own solution to promoting snapshot binaries or just allow CI to re-build it as a production binary. Each approach has tradeoffs.