Desired behavior
I would like to use CYPRESS_DOWNLOAD_MIRROR pointing toward my artifactory configuration for Cypress and just be able to do npm install and download library AND binary of Cypress
Current behavior
When setting Cypress in artifactory, and downloading it with CYPRESS_DOWNLOAD_MIRROR set toward this tool, the download script find binary files as X.Y.Z and not cypress.zip and fail. Apparently I can't rename binaries in artifactory. It seems to have made it available in a name X.Y.Z instead of cypress.zip
My artifactory admin tell me to do this command before but I can't since it's a post action of Cypress
curl –v « https://artifactory.mycompany.fr/artifactory/remote-download.cypress-generic/desktop/6.8.0?platform=win32&arch=x64 » > cypress.zip
Workaround
For now, I'm using CYPRESS_INSTALL_BINARY to point to a manually uploaded binary in artifactory but it's a pain because I have to separate Linux binary (for CI) and Windows binary (for dev) and if my package is configured with "cypress": "^6.2.1" the npm library will go to 6.2.1 and my binary will stuck to 6.2.0 for example...
Debug logs
Installing Cypress (version: 6.8.0)
× Downloading Cypress
→ Cypress Version: 6.8.0
Unzipping Cypress
Finishing Installation
The Cypress App could not be downloaded.
Does your workplace require a proxy to be used to access the Internet? If so, you must configure the HTTP_PROXY environment variable before downloading
Cypress. Read more: https://on.cypress.io/proxy-configuration
Otherwise, please check network connectivity and try again:
URL: https://artifactory.mycompany.fr/artifactory/remote-download.cypress.io/desktop/6.8.0?platform=win32&arch=x64
Error: self signed certificate in certificate chain
Download method
npm
Operating System
Linux
Windows
Other
I'm behind a proxy
I don't really know if it's an artifactory or a Cypress matter but I need help ^^
In addition to accepted answer, it is possible to replace pre-defined 'Query Params' with enabling 'Propagate Query Params'. If set, the query params passed with the request to Artifactory, will be passed on to the remote repo.
Please note, according to JFrog docs, this setting is only available for Generic type repositories.
I was able to make it work on Windows using the following:
I created a generic remote repository, making sure it is pointing to https://download.cypress.io, and under the advanced tab, added the query params: platform=win32&arch=x64 (notice there is a dedicated field for it).
The above is required in order to cache the correct binary based on the OS and arch (you might require a different remote repository with different query params).
I found it on Cypress doc that these query params control the binary type which will be downloaded (so we need to make sure it fits the client os and arch).
In the .npmrc I simply provided the following:
CYPRESS_DOWNLOAD_MIRROR=https://user:myverystrongpassword#myartifactory/artifactory/generic-cypress-windows
I've used this command (on MacOS) to directly pass path to downloaded Cypress.zip file
CYPRESS_INSTALL_BINARY=~/Downloads/cypress.zip yarn add cypress --D
Related
I'm attempting to use private repositories as go libraries.
Whenever i try to run go get og god mod tidy, i get this kind of error
>go get bitbucket.org/myworkspace/myRepo
go get bitbucket.org/myworkspace/myRepo: reading https://api.bitbucket.org/2.0/repositories/myworkspace/myRepo?fields=scm: 404 Not Found
I've found multiple suggestions to fix this, with git config insteadOf url reqriting, but it doesn't work, and it all seems to assume that go will clone the library repo via git, and not the api.
My colleague who is running Linux, tried this and it worked, and at no point does it appear to use api.bitbucket.org instead of just bitbucket.org.
I've tried calling https://api.bitbucket.org/2.0/repositories/myworkspace/myRepo?fields=scm via Insomnia, with credentials, and i get the repo back just fine.
Why does go use the bitbucket api on windows, and how can i have it use credentials, so it can find the repo ?
This is due to a change made by Bitbucket (rolling out from June 1st 2022):
Rolling out these changes will break previous versions of Go due to the fact that the go command relies on a 403 response to fetch repositories hosted on Bitbucket Cloud. This means that users who use older versions of Go with private repositories, for example CI/CD builds with Go dependencies, will run into 404 errors.
Go has been updated to support these changes; version 1.18 includes the change but if you are running an earlier version you may need to upgrade to a later minor revision (change is in 1.17.7 and 1.16.14). The relevant Go issue is here (the aim of the change is something different but it resolves the issue).
Why does go use the bitbucket api on windows...
Go was using the API to determine if the Bitbucket repo was using Git or Mercurial (Bitbucket is dropping support for Mercurial).
As mentioned in the comments I've found that the new Git Credential Manager removes the need for the workarounds previously required to access private Bitbuicket repos. Using the credential manager and setting GOPRIVATE was all that was needed..
You can first export the private repository with the command export GOPRIVATE=<remote module name>. Then you can run the command env GIT_TERMINAL_PROMPT=1 go get <remote module name> so that if the credentials are not configured, you get a prompt.
We are running a local Artifactory Pro installation and have rubygems.org configured as a Remote Repository.
When running bundle install in a CI Job, the local Artifactory Instance does return a 404 File not found when querying for the /versions file. When doing a manual lookup in the Remote (&Cache) Repo, the file >is present<.
The path we pass to bundle install is provided by the Set me up Wizard and looks like this:
https://$rtf-instance.com/artifactory/api/gems/gems-remote/versions
This was mentioned in an issue here: https://www.jfrog.com/jira/browse/RTFACT-16005
and should have been fixed, but it is still not working in our installation.
Can't find any mention of RTFACT-16005 or the related RTFACT-19012 in the Release Notes.
Repo is setup with default values, no additional config done.
Are we missing something?
Environment:
debian 10 (buster)
nginx 1.14.2
artifactory-pro 7.15.4 / 7.15.3
To enable the gems compact index support you need to add the following system property (under $JFROG_HOME/var/etc/artifactory/artifactory.system.properties):
artifactory.gems.compact.index.enabled=true
You will need to restart Artifactory afterward.
This can be found in JFrog Wiki, here: https://www.jfrog.com/confluence/display/JFROG/RubyGems+Repositories#RubyGemsRepositories-RetrievingLatestRubyGemsPackageCompatiblewithYourRubyVersions
I am writing a custom terraform provider and have followed all the documented steps in the following URL: https://learn.hashicorp.com/terraform/development/writing-custom-terraform-providers
I am able to get it running with all the CRUD operations with an SDK used for remote service where I am triggering API calls.
However, one issue I am facing is that in case remote URL is unavailable, running a terraform apply overwrites the TF state file even though I am returning an error from the plugin. This error is also reflected in the terraform apply output.
Edit:
Looks like I found steps to replicate this with an existing repository: https://github.com/Mastercard/terraform-provider-restapi/
Observations from this:
If I use the latest release binary from https://github.com/Mastercard/terraform-provider-restapi/releases, it works as expected.
If I clone the repository and build the binary myself using this command go build -o terraform-provider-restapi_v1.10.0-linux-amd64, I start getting the errors as mentioned in the question.
go version: go version go1.10.3 linux/amd64
What am I doing wrong here? How do we build provider binaries?
Any help on how to correct this?
I think this is a very common issue among those who want to use Cargo with Windows at work; I have seen multiple GitHub issues and forum posts related to it, but none of the answers solved my problems.
Whenever I try to build some code pointing to a crates.io crate, I get the following error:
Downloading <package>
error: unable to get packages from source
Caused by:
failed to download package <package> from <package address>
Caused by:
SSL connect error
What can I do to fix this? I know that Cargo can use the settings at .cargo/config and that the proxy details can be included there, but it doesn't work for me, with or without specifying the path for the certificate (I used the one distributed with curl), like below:
[http]
proxy = "http://user:password#proxy-address.xyz:port"
cainfo = "cert.pem"
[https]
proxy = "https://user:password#proxy-address.xyz:port"
cainfo = "cert.pem"
The proxy specified in the config file works for any other purpose.
I'm using Windows 7 64bit, Rust 1.11 GNU and Cargo bundled with it. How can I get this working? Currently I have to resort to downloading crate sources manually from their repositories and specifying paths = [...] for each of them in the Cargo config file.
I had the same problem, and I solved simply setting environment variables http_proxy and https_proxy with http(s)://user:password#proxy-address.xyz:port.
The only annoiyng part is that, when you need to unset the proxy (e.g. when you are smart-working from another network without using company's VPN) you have to unset / delete those variables.
It appears that this is no longer an issue as of cargo 0.13 bundled with Rust 1.13 stable - I no longer need to manually download packages and put them in paths in cargo's config file.
I have been quite successfully using CMake to perform builds using the ExternalProject_Add function, but my company recently put in a proxy server... Which has broken the aforementioned build scripts.
The download step fails during the extract phase because the tarball that was downloaded is only the redirect request from the proxy server (at least I think this is what is contained in the tiny tarball it acquires).
I found this post on the CMake mailing-list. I thought maybe if it worked for the file() command it might work for the ExternalProject_Add() command. I set both http_proxy and HTTP_PROXY environment variables, but still received the same error. I have thought about overriding the DOWNLOAD_COMMAND argument with a wget call since this command seems to behave with the proxy settings. However, I wanted to know if there was a better way.
UPDATE 1: I checked the contents of the small tarball, and it does contain HTML; however, it is a notification that Authentication is required. I'm not sure why it is requiring authentication because I haven't had to enter any login information for wget. wget shows the following output:
Resolving webproxy... 10.0.1.50
Connecting to webproxy|10.0.1.50|:80... connected.
Proxy request sent, awaiting response... 200 OK
Download begins here...
UPDATE 2: I have also noticed that both apt-get and svn fail with this new proxy setup, but git does not... svn complains about "Server sent unexpected return value (307 Proxy Redirect)..." Very confusing...
Thanks!
What version of CMake are you using? The file(DOWNLOAD command started using the follow redirect flag in version 2.8.2, introduced by the following commit:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ef491f78218e255339278656bf6dc26073fef264
Using a custom DOWNLOAD_COMMAND is certainly a reasonable workaround.