search

opentdf / platform

OpenTDF Platform monorepo enabling the development and integration of _forever control_ of data into new and existing applications. The concept of forever control stems from an increasingly common concept known as zero trust.
BSD 3-Clause Clear License
17 stars 5 forks source link

platform releasing: Auto-update (dependabot?) after module releases #839

Open dmihalcik-virtru opened 3 months ago

dmihalcik-virtru commented 3 months ago

When we tag a new release (currently, by approving a release-please generated PR) we should get a follow-up PR (or automatically generate and push a commit) that updates internal deps to use the new release.

For example, once https://github.com/opentdf/platform/pull/805 was merged, we could have generated a subset of the https://github.com/opentdf/platform/pull/815/files#diff-cd249c062d77b4d6a5621756423850d0708ffbe4aae554ce33cdc5b908b0ee39R7

which just updated all uses of platform/sdk in go.mods

dmihalcik-virtru commented 3 months ago

After some investigation, it appears that we can pre-compute the go.sum. So it is possible that we could do a release that updates multiple packages at once - e.g. if protocol/go is updated, we can tag the same commit as released for protocol/go, sdk, and service.

However it may conflict with the merge queue approach - we'd have to somehow update the sum during the merge queue step if we want the release to be on main. So we could have releases be only on long-lived branches, or deal with a lot of merge queue failures due to mismatched go.sums if the contents of a module change due to merge queue conflicts.

For now I'm going ahead with the approach of two PRs per release, one that does the release and updates the changelog (the current automation) and then adding a second PR that updates downstream deps. Ideally we'd get to one PR per release but it may not be possible, due to the complexity of a solution (hand-rolling our own go.sum updates), competition with the merge queue (any changes to module content between PR approval and the merge event will bounce the release PR), and the fact that a job can only tag at most 3 releases at once (not sure about that). All are surmountable, but will take more time.