ci(shipjs): also push tags of non-published packages #5230
Conversation
These tags get used to determine the next version number, and as we can't get rid of version number (yarn wouldn't include the package into the dependencies otherwise), that's required to be correct. This also fixes a little error in one example package accidentally set to public
Haroenv
requested review from
a team,
dhayab and
sarahdayan
and removed request for
a team
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 1936604:
|
| if (releaseType === 'patch' && fix === 0) { | ||
| return false; | ||
| } | ||
| shouldPrepare: () => { |
There was a problem hiding this comment.
Because the package returned from version possibly doesn't have any relevant pushes, while other packages would have stuff to release. Therefore I think it's best if we get the pr every two weeks and choose to close if it's irrelevant
There was a problem hiding this comment.
I think we need to document this process so we're all fully aware of it and can manage it. For now it's blurry to me how things would go and what are the different possible scenarios.
Also, we need to better handle this for when we have feature teams contribute, we can't be the only ones on duty of merging release PRs in the long run.
There was a problem hiding this comment.
Is what's described in algolia/shipjs#986 sufficient? For now if a release is prepared, but none of the packages requires that update, shipjs will still prepare the release, possibly doing a useless release (not that big of a deal) that we can manually cancel if we don't think it's needed to release just yet, similarly as already happens from time to time today when the only changes are minor things that don't need to be released
There was a problem hiding this comment.
Got it. I created a Jira ticket so we handle this quickly, I'm not fond of such a manual process to last too long.
Summary
These tags get used to determine the next version number, and as we can't get rid of version number (yarn wouldn't include the package into the dependencies otherwise), that's required to be correct.
This also fixes a little error in one example package accidentally set to public
Result
every package will get a git tag, to make sure the next version number will be correct.