fix #8171: Upgrade vscode-ripgrep to 1.8.0

[datou0412]

Signed-off-by: 二凢 [email protected]

What it does

Fixes: #8171

Upgrade vscode-ripgrep to 1.8.0.

How to test

• yarn start:browser
• open a workspace
• search in workspace
  
• quick open any file
  

Review checklist

• as an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• as a reviewer, I agree to behave in accordance with the review guidelines

[vince-fugnitto]

@datou0412 thank you for the fix, please take a look at the CI as all the tests are currently failing.

[shahidhs-ibm]

+1

We want to upgrade vscode-ripgrep version for different reason. The current version of vscode-ripgrep in che-theia i.e. 1.7.0 resolve to ripgrep version v11.0.1-6 which don't have support for s390x in their release for unknown reasons.
This is causing below error when we are trying to build che-theia on s390x:

#50 245.0 error /home/theia-dev/theia-source-code/che-theia/node_modules/vscode-ripgrep: Command failed.
#50 245.0 Exit code: 1
#50 245.0 Command: node ./lib/postinstall.js
#50 245.0 Arguments:
#50 245.0 Directory: /home/theia-dev/theia-source-code/che-theia/node_modules/vscode-ripgrep
#50 245.0 Output:
#50 245.0 Finding release for v11.0.1-6
#50 245.0 GET https://api.github.com/repos/microsoft/ripgrep-prebuilt/releases/tags/v11.0.1-6
#50 245.0 Deleting invalid download cache
#50 245.0 Downloading ripgrep failed: Error: Asset not found with name: ripgrep-v11.0.1-6-s390x-unknown-linux-gnu.tar.gz
#50 245.0     at getAssetFromGithubApi (/home/theia-dev/theia-source-code/che-theia/node_modules/vscode-ripgrep/lib/download.js:188:15)
#50 245.0     at process._tickCallback (internal/process/next_tick.js:68:7)
#50 245.0 info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
#50 ERROR: executor failed running [/bin/sh -c if [ -z $GITHUB_TOKEN ]; then unset GITHUB_TOKEN; fi &&     cd plugins && ./foreach_yarn]: buildkit-runc did not terminate successfully

Upgrading vscode-ripgrep version to 1.8.0 will resolve the issue for s390x.

[vince-fugnitto]

I verified the changes and they look good 👍

• verified that search-in-workspace still works correctly
• verified that file-search works still correctly
• verified that the updated dependency is license compatible using our procedure

[marcdumais-work]

I just restarted the failed CI build after clearing its Travis cache.

[marcdumais-work]

It failed again :(

@datou0412 : the way this PR works, we are changing the version range for our vscode-ripgrep runtime dependency, so that the minimal acceptable version is the (currently) latest one, that correctly supports working behind a proxy to fetch the ripgrep executable, after npm package install.

That's arguably one way to go about it. However it would also work to remove the vscode-ripgrep entry from the repo's yarn.lock and rebuild - the latest version then would be picked-up and saved in yarn.lock, which we can then check-in.

The main difference is that, with the later approach, we leave downstream projects free to continue to use their current vscode-ripgrep version if they want, that's currently pinned in their app's yarn.lock. Probably many will want to switch to the latest version, but there could be some who will not. Should we force them?

[marcdumais-work]

It failed again :(

I believe that the failure is unrelated to the content of the PR. The root cause is probably that the PR originates from a fork and so the encrypted environment variables are disabled:

https://travis-ci.com/github/eclipse-theia/theia/jobs/363120105#L75

One such variable is the GitHub token. Not having it usually results in frequent failure to download the ripgrep executable from GitHub (unauthenticated API rate limit), and consequently the failure of CI tests that rely on ripgrep

In theory we should be able to get it to pass eventually if we re-try a few times.

[datou0412]

It failed again :(

I believe that the failure is unrelated to the content of the PR. The root cause is probably that the PR originates from a fork and so the encrypted environment variables are disabled:

https://travis-ci.com/github/eclipse-theia/theia/jobs/363120105#L75

One such variable is the GitHub token. Not having it usually results in frequent failure to download the ripgrep executable from GitHub (unauthenticated API rate limit), and consequently the failure of CI tests that rely on ripgrep

In theory we should be able to get it to pass eventually if we re-try a few times.

Should I do something?

[marcdumais-work]

@datou0412 : the way this PR works, we are changing the version range for our vscode-ripgrep runtime dependency, so that the minimal acceptable version is the (currently) latest one, that correctly supports working behind a proxy to fetch the ripgrep executable, after npm package install.

That's arguably one way to go about it. However it would also work to remove the vscode-ripgrep entry from the repo's yarn.lock and rebuild - the latest version then would be picked-up and saved in yarn.lock, which we can then check-in.

The main difference is that, with the later approach, we leave downstream projects free to continue to use their current vscode-ripgrep version if they want, that's currently pinned in their app's yarn.lock. Probably many will want to switch to the latest version, but there could be some who will not. Should we force them?

@akosyakov Do you have an opinion on this? A minimal fix would not require changing the dependency's version range but also would not affect/benefit downstream projects unless they also upgrade their yarn.lock for this dependency.

[marcdumais-work]

Should I do something?

Nothing to do I think about the failing CI.

[marcdumais-work]

If we go with the dependency range change, it might be good to mention it in CHANGELOG.md - it might break downstream builds if they use yarn --frozen-lockfile

[marcdumais-work]

@datou0412 unless another project committer chimes-in with a contrary opinion, I would prefer a solution that imposes as little as possible on downstream projects. In this case it would mean leaving the version range for vscode-ripgrep as it is on master and instead updating the related entry in yarn.lock.

[marcdumais-work]

In this case it would mean leaving the version range for vscode-ripgrep as it is on master and instead updating the related entry in yarn.lock.

I have created a PR that does this: #8280

[marcdumais-work]

This PR is now obsolete, following #8280 being merged. Closing