-
Notifications
You must be signed in to change notification settings - Fork 27
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
GH-37 patch release updates for 1.3.1 #38
Conversation
when using file:path/to/plugin
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All the changes looks OK to me.
@@ -154,7 +155,7 @@ function trimID (target) { | |||
var gitInfo = hostedGitInfo.fromUrl(target); | |||
if (gitInfo) { | |||
target = gitInfo.project; | |||
} else if (isUrl(target)) { | |||
} else if (isUrl(target) || isGitUrl(target)) { | |||
// strip away .git and everything that follows | |||
var strippedTarget = target.split('.git'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Though this was not introduced from any of these changes in the PR. I just happened to have noticed this when reading the diffs and wanted to point it out.
If for any reason the target was https://scm.git.foobar.com/secret/repo.git
, it would match on scm
and not repo
. If written in SSH format git@scm.git.foobar.com:secret/repo.git
, it would error out.
A real example would have been cloning from a gists.
https://gist.github.com/sample.git
or git@gist.github.com:sample.git
but luckily the Gist URL format is covered by the first if condition and is not a problem.
var gitInfo = hostedGitInfo.fromUrl(target);
if (gitInfo) {
Anyways, just pointing out something I noticed when looking over the line. Most users use anyways GitHub, Gitlab, and BitBucket which the first condition covers. +Gist
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that this code has entirely vanished in the master branch, I would not bother to fix this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Perfect for a new issue)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I should have looked at master before writing and re-writing my paragraph HA.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@erisu I think the perfect sample finally came to me after working all day on unit testing it: it would be possible for a user to do cordova plugin add https://scm.git.foobar.com/secret/repo.git#1.0.0
, expecting to get 1.0.0
release tag, but end up with the default branch due to the bug you found in this PR. Considering that this change is both broken and gone in master
I would say that it should either be reverted or removed by rebase. I will deal with this another day.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixing or reverting the change is not required. You can keep the changes in.
As @raphinesse said, and as I mentioned earlier, this bug actually existed even before the change.
I just happened to have noticed it while reading the change diff. It was not introduced in any of these changes. And being that this entire area of the code was removed from master it won't be a future issue.
Regarding the actual change itself, it might have fixed the user's use case and will provide support too additional git services, but it might be that most service's URL structure fits properly.
Anyways at this point, the changes are OK and releasable.
Sorry for the confusion. 😆
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@erisu you are right that the bug did exist before the change, but I think it was only in case of URL not starting with git://
. The change here will now trigger the bug in case of a URL starting with git://
. While this would be an extremely rare bug I would rather not introduce another case of such a bug in a patch release if we can avoid it somehow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@brodybits I tried running this sample git://scm.service.io/user/my-repo.git
through the method and I still got back the repo name my-repo
as expected.
The only case where I saw this rare issue to occur was when the URL had two or more .git
.
In the following lines parts = strippedTarget[0].match(re);
, it expected that index 0 of strippedTarget to contain the entire URL minus the .git
.
Example: https://scm.service.io/user/my-repo
It would then grab the item after the last /
.
In the rare faile case, if the URL was https://scm.git.service.io/user/my-repo.git
, it would slit on all .git
and in this case, index 0 becomes https://scm
.
It believes the repo name is scm
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Make sure to transform those into test cases for the test suite)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't get why we are still discussing this. The patch fixes some use cases but breaks no previously working ones. So it should be included.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The last two changes in 30d05ba were not part of the original commit, but probably part of the "Let jasmine handle promises" commit.
Other than that, this looks good.
to reduce spurious failures I just doubled timeouts until it worked on my local machine. The real problem is that we are cloning 50MB worth of git repos over the network in some tests.
Needed to support fs-extra in spec only in patch release FUTURE TBD may be removed from devDependencies if [apacheGH-23] shelljs -> fs-extra is completely ported to 1.3.x. NOT WANTED in master
partial cherry-pick from master, shelljs still in index.js & fetch-unit.spec.js FUTURE TBD: cherry-pick remaining changes & remove fs-extra from devDependencies
to avoid caching
This should not change the test coverage at all. It only factors out commonly used patterns into functions. Best viewed with --anchored=describe
This is actually part of the previous commit, but committed separately to have readable diffs.
- Reduce run time of longest test [...] - Reduce amount of git tests for double fetch tests
- eslint@4 devDep update - in-range eslint-* devDep updates
(already done on master)
(cherry-pick from apacheGH-36)
spec/support/dummy-local-plugin/plugin.xml (copied from cordova-plugin-device)
(in-range update)
0996948
to
17e21e7
Compare
@raphinesse I just rebased with the stray changes in 30d05ba taken out, would like to merge (as a merge commit) once Travis goes green. |
Can't seem to change my review to approval now that the branch is merged. But I approve 👍 |
Changes
master
:spec/support/dummy-local-plugin/plugin.xml
(copied from cordova-plugin-device)master
:npm i --save-dev fs-extra@4
- quick fix needed for [[CB-14140] Remove shelljs #23] shelljs -> fs-extra in spec only (1.3.x)Motivation & rationale:
master
branch which now targets next major release is not desiredSome updates not (yet) included from
master
:spec/fetch-unit.spec.js
) - Isolate Q usage to prepare later removal #17spec/fetch.spec.js
&spec/helpers.js
but not tospec/fetch-unit.spec.js
,index.js
orpackage.json
are cherry-picked in this PR)Testing
npm audit
shows 0 vulnerabilities (npm@6.3.0)npm outdated --depth=0
shows no red entriescoho audit-license-headers -r fetch
shows no missing license headerscoho check-license -r fetch
shows no incorrect licenses (manually verified thatxmldom
has acceptable MIT license option)npm test
& other tasks succeed on AppVeyor CInpm test
& other tasks succeed on Travis CI