Skip to content
This repository has been archived by the owner on Sep 23, 2021. It is now read-only.

Display information about the changesets present #3

Open
Noviny opened this issue Sep 18, 2019 · 2 comments
Open

Display information about the changesets present #3

Noviny opened this issue Sep 18, 2019 · 2 comments

Comments

@Noviny
Copy link
Contributor

Noviny commented Sep 18, 2019

With the release of @changesets/get-release-plan we can get richer information about the existence non-existence of changesets: I think it would be good to change how this action works to something like:

  1. yarn in repo and call getReleasePlan() using { sinceMaster: true }
  2. With the output - check the length of the changesets array to see if there are new changesets ('empty' changesets is a feature we know AK wants that we want this to work with).
  3. If there are, format the data in releases in some way to display this information.

Open questions:

a) is this mad?
b) how do we format the info?

i) probably need to separate packages from dependents here
ii) a table maybe?
iii) Do we include any summary info or leave that for PR-inspection?

Major downside:
requires this doing a yarn install etc

@emmatown
Copy link
Member

yarn in repo

I strongly dislike this and would like to avoid it if possible. Could we bundle get-release-plan? I assume we would have the problem of the action getting out of date but I feel like the versioning parts are stable enough that it won't really be a problem.

a) is this mad?

I like it as an idea

b) how do we format the info?

i) probably need to separate packages from dependents here

SGTM

ii) a table maybe?

My thoughts are that it should be in a table inside a <details> element because huge automatic GitHub comments are annoying.

iii) Do we include any summary info or leave that for PR-inspection?

IMO, don't include it.

@Noviny
Copy link
Contributor Author

Noviny commented Sep 18, 2019

Could we bundle get-release-plan?

We can bundle getReleaseplan probably. Looking at the current script, it bundles node_modules, so we can just piggyback on that functionality but with getReleasePlan included.

Good thought around avoiding the yarn.


My thoughts are that it should be in a table inside a

element because huge automatic GitHub comments are annoying.

IMO, don't include it.

Easy agree on these

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants