Conversation
|
I've slightly lost track of the new release process. Would merging this push a new release to NPM? I'm just conscious we want to be really careful about doing that because all the dependency changes have likely introduced bugs not covered by the tests. |
@JimMadge we can set it up to work how we'd like it to work in the action. My suggestion is that we create a on release step that will trigger a build and deploy to NPM. BUT then we create an environment that is protected to the deploy step won't trigger until a human authorizes it. So we won't merge this until we are confident we are ready for a releae and then there is one last step that a human takes to shoot it over to NPM. We use this type of release workflow with stravalib and it works really well. NOTE: i have NOT setup a deploy workflow yet but #455 is part of that (we need to be happy with the changelog) . and then i'll create a build / deploy workflow that is secured. Right now the test coverage is definitely low. But the other tension is that users are using a 3 year old version of this package that has security issues. So my inclination is that once we have a working CLI and tests are running (and we have a few test related pr's open), we test locally and then deploy to update the NPM version. Then we can backfill tests. in the meantime we can't merge this anyway until we move to ESM as that is a blocker for mocks and we have more dependency updates to do now that kcd-scripts is removed (which are also security related). So we still have more work to do but are getting close to a release (i think!). Does that seem reasonable to you? It's a lot!! |
|
@lwasser Yes I think we are in complete agreement 👍. |
3d9155d to
9647a4f
Compare
Fantastic!! can you take a look at the new changelog format? I'll ping you on the issue/pr!! |
🤖 I have created a release beep boop
6.26.2 (2026-02-25)
Bug Fixes
This PR was generated with Release Please. See documentation.