-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automate GitHub releases #61
Conversation
|
1d6c2e2
to
83fce59
Compare
TBDocs Report ✅ No errors or warnings @tbdex/protocol
@tbdex/http-client
@tbdex/http-server
Updated @ 2023-10-30T22:29:04.701Z - Commit: |
83fce59
to
a107733
Compare
@@ -25,59 +16,7 @@ permissions: | |||
id-token: write # necessary for NPM provenance | |||
|
|||
jobs: | |||
tbdocs-publish: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the plan with this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- keep using the reporter for our regular PRs (it will keep us in check regarding the missing docs and breaking api changes)
- automatically publish the vanilla html generated by typedoc (similarly to dwn-sdk-js one)
- we will link from the developer.tbd.website to this one, instead of publishing it there.
This is fruit of a conversation that I had with @ALRubinger and @mistermoe.
We agreed that developers will prefer to consume the API reference in their own ecosystem instead of getting used to the TBD website theming, which would probably have limitations compared to their natural tools. Think of javadoc for java, docs.rs for rust, pkg.go.dev for go developers and so on...
We started with js which has an ecosystem that most libs have their own website docs, so it was fine, but we are stepping back to a more standard approach, so that the website does not have embedded api references only for the js libs and the rest leaves outside... (cc @angiejones)
on: | ||
pull_request: | ||
types: | ||
- closed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
interesting terminology choice by GitHub here... to me "closed" is not the same as "merged"
this lgtm ✅ but I vote let's hold off until @mistermoe has a chance to look over, which may not be until next week |
@KendallWeihe can I go ahead and merge now? |
@leordev I think we should add some material to the README which explains the way releases work, from the point of a developer opening a PR to the point where they can go to npmjs.com and see the new version I wrote the Changesets section, but it's slightly misleading in that it's descriptive rather than prescriptive. I like what I've written, but it's a little daunting at first glance, and we may be better off to move it somewhere different and have a simple
Do I have it correct? Have we had discussions around documenting release flows? Will release flows be standard across all implementations? |
a107733
to
6d9dd7e
Compare
Co-authored-by: Kendall Weihe <kendallweihe@gmail.com>
ad44caf
to
10a74e1
Compare
Yes!
Done! Check it out: 10a74e1#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5
Not yet, we do have this issue to capture that! And I agree that we should converge into a standard for all implementations. Although each language will have its own toolset. @mistermoe @KendallWeihe about this step: |
I still didn't love my wording, specifically this bit,
...which makes it sound like the developer must execute this step. I took the liberty of adjusting things a bit further 098c1e4 @leordev what'd you think? Feel free to adjust/undo/whatevs. |
# we want to allow these release deployments to complete. | ||
concurrency: | ||
group: ${{ github.workflow }}-${{ github.ref }} | ||
cancel-in-progress: false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there a chance that a deployment can hang, in which we'd want to cancel in progress?
@@ -4,15 +4,6 @@ on: | |||
release: | |||
types: [created] | |||
workflow_dispatch: | |||
inputs: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you give me some context on why this block has been removed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since there's no more docs publishing in the release process it does not make sense to have these options anymore!
0e2d089
to
ed5c22a
Compare
This PR automates the trigger to create a GH Release when a changeset PR is merged.
Fix #60 (see full context context).
(Also it removes the TBDocs from the release pipeline because now we are planning to release default Typedoc similar to the DWN ones).