search

dapr / js-sdk

Dapr SDK for Javascript
Apache License 2.0
198 stars 84 forks source link

chore(release): add support to release dev packages #493

Closed shubham1172 closed 1 year ago

shubham1172 commented 1 year ago

Description

This PR refactors the build pipelines and adds a job to release dev packages (on push to main).

  1. Removes unused script ./scripts/publish.sh
  2. Adds a new command to package.json build-ci to build typescript package without linting or prettifying
  3. Adds new steps to github actions to publish dev package to NPM
  4. Split the github actions into three jobs - build, publish, and publish-dev.

Issue reference

Please reference the issue this PR will close: #492

Checklist

Please make sure you've completed the relevant tasks for this PR, out of the following list:

codecov[bot] commented 1 year ago

Codecov Report

Merging #493 (4440fdf) into main (b4335c1) will decrease coverage by 2.02%. The diff coverage is 3.03%.

:exclamation: Current head 4440fdf differs from pull request most recent head 861fd8f. Consider uploading reports for the commit 861fd8f to get more accurate results

@@            Coverage Diff             @@
##             main     #493      +/-   ##
==========================================
- Coverage   38.74%   36.72%   -2.02%     
==========================================
  Files          82       82              
  Lines        8187     9927    +1740     
  Branches      371      371              
==========================================
+ Hits         3172     3646     +474     
- Misses       4956     6222    +1266     
  Partials       59       59
Impacted Files Coverage Δ
src/implementation/Client/GRPCClient/lock.ts 16.00% <ø> (ø)
src/proto/dapr/proto/common/v1/common_pb.js 30.97% <0.00%> (ø)
src/proto/dapr/proto/runtime/v1/dapr_pb.js 31.43% <ø> (-1.21%) :arrow_down:
src/proto/dapr/proto/runtime/v1/dapr_grpc_pb.js 5.82% <1.05%> (-1.91%) :arrow_down:
src/implementation/Client/DaprClient.ts 83.52% <100.00%> (ø)
shubham1172 commented 1 year ago

Ok for me! Question: don't we want to use the commit sha hash instead of a timestamp?

Good idea, I think SHA will be helpful when users want to associate dev release with a commit - I had kept timestamps only for one reason, easy to find the latest version and based on time. Let me add a go style versioning in that case.

e.g. 3.0.1-20230526200301-0744d001aa84

WDYT @XavierGeerinck?

XavierGeerinck commented 1 year ago

I would personally just do the sha hash :)

shubham1172 commented 1 year ago

Since short hashes can have collisions, we should either use

  1. timestamp + short hash
  2. long hash
XavierGeerinck commented 1 year ago

Since short hashes can have collisions, we should either use

  1. timestamp + short hash
  2. long hash

Good point, ok then we can use your proposal