feat: make a wrapper script for Lerna that autodetects the right remote #638
Conversation
As I discovered in my first attempt at publishing the JS toolkit
yesterday, Lerna will push to your "origin" remote, which in my case was
my fork; ie. my `git remote -v` output is:
origin git@github.com:wincent/liferay-js-toolkit.git (fetch)
origin git@github.com:wincent/liferay-js-toolkit.git (push)
upstream https://github.com/liferay/liferay-js-toolkit.git (fetch)
upstream https://github.com/liferay/liferay-js-toolkit.git (push)
upstream-rw git@github.com:liferay/liferay-js-toolkit.git (fetch)
upstream-rw git@github.com:liferay/liferay-js-toolkit.git (push)
This commit adds a wrapper that uses this pipeline to try and pick the
right remote automatically:
- `git remote -v`: list all remotes.
- `grep 'github.com[:/]liferay/'`: Pick out "liferay" ones.
- `grep '(push)'`: Ignore "(fetch)" URLs, look at "(push)" URLs.
- `sort -k2`: Sort by column 2 (URL); this prioritizes SSH URLs.
- `head -1`: Grab winner.
- `cut -f1`: Print the name (ie. "upstream-rw").
We prefer SSH URLs because they are more likely to be the preferred URLs
for write access.
Updated the docs accordingly.
Test plan:
1. Prepended "echo" to those "yarn" commands so that I could run without
actually publishing.
2. Run "yarn release"; see it print:
```
yarn run lerna --help --force-publish=* --exact --git-remote=upstream-rw
```
3. Edit then "grep" to search for "liferayz" instead of "liferay"; see:
```
warning: could not locate a "liferay" remote
Proceed using "origin" remote? n
Aborted.
```
4. Repeat, but this time answer "y":
```
warning: could not locate a "liferay" remote
Proceed using "origin" remote? y
yarn run lerna --force-publish=* --exact
```
|
Forgot to add: And also, I originally wrote this as a JS script, but switched to Bash when I released you can't do a real |
|
I would migrate it to JS so that it is multiplatform if it is not too much work. In the past we had unix scripts and people had problems contributing to the repo so I now do everything in pure JS and slowly migrate remaining scripts. In this case, if it is too much work, we can leave it like this as it is only for release and only @wincent and me publish releases. Also, I would have to test it in Linux, given that some commands differ between Mac (~BSD) and Linux. I'm specifically worried about the |
|
Sorry , I didn't read this:
So I guess we can merge 🤷 |
Yep, it's a good practice, and why I started in JS. But I had the same thought you did that the only people who will run Tested on Linux (well, on Amazon Linux): |
|
The |
|
Going to merge this and try it out. The only way to do a real end-to-end test is to actually cut a release, which we need to do anyway. |
As noted here: #638 (comment) > The only way to do a real end-to-end test is to actually cut a > release, which we need to do anyway. And indeed, when we try it, we see: ERR! lerna A command is required. Pass --help to see all available commands and options.
|
Needed this little hotfix. 😀 |
As I discovered in my first attempt at publishing the JS toolkit yesterday, Lerna will push to your "origin" remote, which in my case was my fork; ie. my
git remote -voutput is:This commit adds a wrapper that uses this pipeline to try and pick the right remote automatically:
git remote -v: list all remotes.grep 'github.com[:/]liferay/': Pick out "liferay" ones.grep '(push)': Ignore "(fetch)" URLs, look at "(push)" URLs.sort -k2: Sort by column 2 (URL); this prioritizes SSH URLs.head -1: Grab winner.cut -f1: Print the name (ie. "upstream-rw").We prefer SSH URLs because they are more likely to be the preferred URLs for write access.
Updated the docs accordingly.
Test plan:
Prepended "echo" to those "yarn" commands so that I could run without
actually publishing.
Run "yarn release"; see it print:
Edit then "grep" to search for "liferayz" instead of "liferay"; see:
Repeat, but this time answer "y":