publish snapshot releases on every merge to main #438
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
TBDocs Report 🛑 Errors: 0 @web5/api
@web5/crypto
@web5/crypto-aws-kms
@web5/dids
@web5/credentials
TBDocs Report Updated at 2024-03-15T17:09:50Z |
finn-block
force-pushed
the
snapshot-releases
branch
from
9b0acb0 to
97bc1d8
Compare
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #438 +/- ##
=======================================
Coverage 93.35% 93.35%
=======================================
Files 80 80
Lines 23839 23839
Branches 1891 1891
=======================================
Hits 22255 22255
Misses 1544 1544
Partials 40 40
|
finn-block
force-pushed
the
snapshot-releases
branch
from
94d71fd to
4c9d48e
Compare
finn-block
changed the title
finn-block
requested review from
frankhinek,
csuwildcat and
mistermoe
as code owners
leordev
reviewed
Mar 11, 2024
|
@finn-tbd Is it possible to publish the short SHA in the version If no, how does a consumer of the published release know which commit it is associated with? I'm imagining a scenario where a downstream consumer reports they ran into an issue/bug with |
|
It's possible, but that would break npm's versioning scheme. in particular, it would make it unable to determine which is the latest snapshot. If that's something we're super concerned about, we could combine the two approaches (ie. |
Can you elaborate on the concern? Based on Do we really want |
finn-block
force-pushed
the
snapshot-releases
branch
from
f21d52d to
9b55357
Compare
correct
I would expect the latest version in the snapshot repository to be the latest snapshot. If we just used the SHA and had no count, it would still install a snapshot release, it just wouldn't be the latest one. I'm not 100% sure how it would pick but i think it would be the (alphabetically) highest SHA, so closest to i've updated it to include the SHA in the snapshot version, so version numbers are computed like this: snapshot_version="${base_version}-SNAPSHOT.${commits_since_version_bump}-${last_commit_to_package:0:7}"for example, |
frankhinek
suggested changes
Mar 15, 2024
| with: | ||
| cache: "true" | ||
|
|
||
| - uses: jfrog/setup-jfrog-cli@v4 |
There was a problem hiding this comment.
Since the security tools added by OSP raise security issues as a result of unpinned actions, please use the hash and include a comment with which version it is.
Otherwise looks good to ✅ and merge
There was a problem hiding this comment.
whoops, thanks for catching that. Also pinned cashapp/activate-hermit above
There was a problem hiding this comment.
no worries. thanks! nice work @finn-tbd
frankhinek
approved these changes
Mar 15, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is part of a project being undertaken by OSP to help new code make it's way to TBD's downstream projects faster. It creates a snapshot release for each merge to main, which is published to our Artifactory* registry. Once this is done, downstream projects (ie. tbdex-js and developer.tbd.website) can pull in new web5-js features before a real release has been produced by depending on the snapshot version.
It creates snapshot release for any packages that have changed since the last snapshot version. It does this by counting the number of commits in each package since the last time the
package.jsonversion was changed, and producing a snapshot release name in the format<version>-SNAPSHOT.<commit count>(for example, there have been 55 commits that touchedpackages/apisince it was bumped to0.8.4, so it will produce snapshot version0.8.4-SNAPSHOT.55). EDIT: this format has changed slightly to include the sha of the last commit as well, see thread. It checks if a snapshot with this version has already been published, and if not it builds and publishes the snapshot release.Once that has been published, someone writing documentation for developer.tbd.website can set the example to depend on
@web5/apiversion0.8.4-SNAPSHOT.55and write sample code that can be validated against that snapshot.*Artifactory: behaves like npmjs.com, but isn't real npmjs.com so the high number of releases this creates will not spam up our npmjs.com page.