Skip to content
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

Automatic releases of the GraphQL-CLI #1473

Open
wtrocki opened this issue Sep 30, 2020 · 13 comments
Open

Automatic releases of the GraphQL-CLI #1473

wtrocki opened this issue Sep 30, 2020 · 13 comments

Comments

@wtrocki
Copy link
Collaborator

wtrocki commented Sep 30, 2020

Releases are done currently from master, but it will be great to be able to release things from releases tab etc. Current release script were failing to me (Were getting 404 for npm when trying to publish packages)

https://github.com/Urigo/graphql-cli/blob/master/scripts/release.js

@wtrocki
Copy link
Collaborator Author

wtrocki commented Sep 30, 2020

@ardatan @dotansimha If you have example of the release process that we can follow or any links to how this is setup that will be awesome.

@ardatan
Copy link
Collaborator

ardatan commented Sep 30, 2020

We are using changesets in GraphQL Codegen, GraphQL Mesh and GraphQL Tools.
https://github.com/dotansimha/graphql-code-generator/tree/master/.changeset

So you add changelogs in your PRs then it creates a PR for releasing packages when your PRs are merged.
For example,
This PR has changelog which is created by yarn changeset command. Then it's merged;
dotansimha/graphql-code-generator#4823
But before merging, our GH action releases canary versions on every push.
After that, changeset created this PR;
dotansimha/graphql-code-generator#4824
When you merge this one, it will release the packages into NPM.

@wtrocki
Copy link
Collaborator Author

wtrocki commented Sep 30, 2020

@ardatan yep. Seen that repo. I was looking into how we can compose changesets from underlying technologies. We will investigate and move to changesets in graphback and then experiment how to get that into the repo here.

@wtrocki
Copy link
Collaborator Author

wtrocki commented Sep 30, 2020

CC @craicoverflow

@ardatan
Copy link
Collaborator

ardatan commented Sep 30, 2020

@wtrocki It also helps us to maintain packages seperately by following semver.
For example, React-Apollo has many breaking changes that need breaking changes on codegen plugin as well. But we didn't want to publish a major release for all codegen packages then we only published react-apollo plugin as v2.

@wtrocki
Copy link
Collaborator Author

wtrocki commented Sep 30, 2020

Yep.. Very aware of the famous "React Apollo" update :D and how nicely codegen managed to get around it.

@wtrocki
Copy link
Collaborator Author

wtrocki commented Sep 30, 2020

@ardatan in more recent matters. Could you try if you can release v4.1.0-beta2 orsomething using current scripts.
Things are failing for me with 404 that makes no sense. If that fails for you will give me some context.

@wtrocki
Copy link
Collaborator Author

wtrocki commented Oct 6, 2020

@ardatan Update. We cannot use current script so going to use lerna for releases.

@ardatan
Copy link
Collaborator

ardatan commented Oct 7, 2020

@wtrocki We could have helped you switching to changesets instead of lerna because we removed lerna on purpose a while ago.

@dotansimha
Copy link
Collaborator

dotansimha commented Oct 7, 2020

Agree with @ardatan on that. We decided to drop Lerna since Yarn Workspaces manages deps linking for us, and there is no reason to use Lerna for releases only.
We are using changesets in all our other OSS projects, and so far it's amazing. It allow to to break the versioning links and have automatically managed changelogs, version bump and semver support.
We don't want automatic releases, we prefer to have changesets with canary releaes, based on changesets and PRs. Then, to trigger a release, you just merge PR that changeset-bot creates for you. Super simple, and managed automatically.

@wtrocki
Copy link
Collaborator Author

wtrocki commented Oct 7, 2020

@ardatan yep. There is short term plan and long term plan.

  • Short term is to be able to do release using github releases flow. This is critical as local development doesn't do full checkout, Some typings might be lost or extra files published that might not be there.

  • Long term is to move entire stack to workflow that you have been using.
    Generally our team has very strong target towards processes. We document releases and how they are done: https://github.com/aerogear/graphback/blob/master/scripts/release-procedure.adoc

We are using changesets in all our other OSS projects,

I have seen changesets being used but did not seen how to use it. Any link will help us to add it here.

@wtrocki
Copy link
Collaborator Author

wtrocki commented Oct 7, 2020

We simply want to release cli for now- there was no release for 4 months and local release fails with 404. For changesets we actually have added lerna chanelog recently (Moving to changesets will require us to do some investigation and do graphback first and document the process). Then we can move that to cli by exposing changelogs.

@wtrocki
Copy link
Collaborator Author

wtrocki commented Oct 7, 2020

TL;DR - We will do changesets 100% but I do not feel comfortable to drop it in hurry without understanding the process (especially on graphback where we have it perfected), but in timeframe of couple weeks we will be ok to move.

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

No branches or pull requests

3 participants