graphql-cli
graphql-cli copied to clipboard
Urigo
Automatic releases of the GraphQL-CLI
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
@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.
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;
https://github.com/dotansimha/graphql-code-generator/pull/4823
But before merging, our GH action releases canary versions on every push.
After that, changeset created this PR;
https://github.com/dotansimha/graphql-code-generator/pull/4824
When you merge this one, it will release the packages into NPM.
@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 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.
Yep.. Very aware of the famous "React Apollo" update :D and how nicely codegen managed to get around it.
@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.
@ardatan Update. We cannot use current script so going to use lerna for releases.
@wtrocki We could have helped you switching to changesets instead of lerna because we removed lerna on purpose a while ago.
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.
@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.
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.
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.