Support multi-package releases#64
Conversation
|
This is a pre-requisite for braintrustdata/autoevals#204 and may also be beneficial for braintrustdata/braintrust-sdk-javascript#2216 |
| set -euo pipefail | ||
| if [ -n "$PACKAGES" ]; then | ||
| # Accept a bare array of entries or a {"packages":[…]} wrapper. | ||
| M="$(jq -c 'if type=="array" then {packages: .} elif .packages then {packages: .packages} else {packages: []} end' <<<"$PACKAGES")" |
There was a problem hiding this comment.
I would just make this very strict from the get-go. We don't have any consumers yet. Ie just accept {"packages":[…]} - no top level array.
Also, I would fail in case there is an invalid manifest instead of defaulting to an empty array.
| @@ -1,67 +0,0 @@ | |||
| name: Prepare Release | |||
There was a problem hiding this comment.
We still need to update a bunch of comments in the codebase referencing this step. eg grep for "from prepare"
| description: "Fail if the version is already published to the registry" | ||
| description: "Fail if the version is already published to the registry (judges configure's already_published)" | ||
| required: false | ||
| default: 'true' |
There was a problem hiding this comment.
Isn't this defaulting to true in direct conflict with already_publihsed being 1?
Since they both do different things, "Does this version exist?" vs "Should we make it fail?". One thought I had to fix this maybe would be to combine them into one thing: "fail" or "skip"?
I personally would even gravitate towards entirely removing it and always just using skip. I don't see myself ever wanting to fail an entire manifest when one package publish fails I think.
There was a problem hiding this comment.
I personally would even gravitate towards entirely removing it and always just using skip. I don't see myself ever wanting to fail an entire manifest when one package publish fails I think.
I think this makes sense in a multi-package workflow (allows self-healing by default), but the default case here is single package workflow where failing prevents a superfluous ping for approval for a release that isn't going to do anything anyways. I lean towards keeping this as is.
cf6efd2 to
1284f2c
Compare
1284f2c to
f9201af
Compare
2 participants
This pull request attempts to simplify the mechanics for multi-package release workflows by:
configureandprepare)request-approvalto enumerate multiple packages in its descriptions/messaging (via package manifest)In sum, this should make it easier to build and deploy release workflows for repositories that need to release multiple packages in a single workflow.