Releases are triggered by code review

[BigLep]

Done Criteria

1. The to-be-created release steps outlined in Create updated release process #2018 can be followed without requiring manual clicking in the GitHub UI. Instead, releases should occur as a result of an approved PR.

Why Important

1. Less time used by maintainers
2. Not bottleneck on certain folks to publish
3. Less error prone

User/Customer

Maintainers

Notes

1. This is more of a standard Rust repo and should be published to crates.io
2. There are multiple branches with different versions that we would want handled

[BigLep]

For visibility, the aspect of creating tags and GitHub releases based off a PR is happening in #2027 . That PR doesn't handle artifact publishing.

[rjan90]

Closing this ticket because, without crate publishing, the automated workflow was not sufficient to move forward. See the comment here for details.

We have documented the manual steps and the manual release process steps here: Manual Release Process

[BigLep]

@rjan90 : feel free to disagree, but I think we should still keep this open since we still want to get to a world where the whole release flow is automated and doesn't require manual steps. Since we haven't reached that goal yet, I think this is still open. (I'll reopen for now because of this, but go ahead and close if you disagree.)

[BigLep]

Proposed IPDX SoW that we've been discussing (thanks @galargh):

PR CI workflow:

• find all the crates that need to be published
• publish each crate individually to a “local” registry* in reverse dependency order
• create a draft GitHub release for each crate to be published

Merge CI workflow:

• find all the crates that need to be published
• check if a draft GitHub release exists for each crate to be published
• publish each create individually to crates.io
• publish the GitHub release for each successfully released crate

• there’s no cargo local registry; a workaround using vendored directories or fake registries and replace directives will have to be developed as a prerequisite

Complexity: creating “local” cargo registry, testing

@Stebalien : does this seem right to you?

[Stebalien]

there’s no cargo local registry; a workaround using vendored directories or fake registries and replace directives will have to be developed as a prerequisite

Is this a general comment or part of the "merge CI workflow"? In general, I think a vendored directory is the simplest approach:

• Replace directives (patches) don't work, I tried every which way.
• A local registry is the "correct" way, but I couldn't find an easy-to-use one (they all want to integrate with authentication, etc.). But someone else may have better luck here.

[Stebalien]

But generally, yes.