Scenario:
Code is in Nuget packages, which get pushed to a local Artifactory
respository in Location 1 (DEV/QA). Each code change results in a new version number (i.e. different package, not overwriting existing package).
Artifactory in location 2 (Main colo) has a remote repository that replicates these packages from Location 1.
Artifactories in Locations 3, 4 and 5 (Production colos around the
world) have remote repositories that replicate these packages from
Location 2.
When code is deployed to production SaaS servers, the packages are pulled down from Artifactories in locations 3, 4 and 5.
Problem:
Intermittent problem where packages in remote repositories become expired and give a 404 error when you attempt to download them.
{
"errors" : [ {
"status" : 404,
"message" : "Resource has expired"
} ]
}
Request:
Is there some setting I can set somewhere that will cause resources to NEVER expire? (We have a cap of 100 versions in the original location, to control growth and the downstream remote repositories are set to delete packages when the origin deletes them)
I am unable to find anything in the documentation that even hints this is possible.
Related
We moved to a new authenticated Nexus to act as a proxy to get dependencies.
I've tried to to give SBT (1.1.1) the credentials it needs, in multiple ways, but I always endup getting :
[error] Unable to find credentials for [Sonatype Nexus Repository Manager # nexus3.company.com]
[debug] CLIENT ERROR: Unauthorized url=https://nexus3.company.com/repository/maven2-proxy-all/org/scala-sbt/actions_2.12/1.1.1/actions_2.12-1.1.1.pom
It's repeated for a lot of dependencies.
I've created a .credentials file in my project as follow:
realm=Sonatype Nexus Repository Manager
host=nexus3.company.com
user=xxxxx
password=xxxxx
Here's what I've tried, based on inputs I got from other threads on the internet:
Adding the path to this credentials file in the command : -Dsbt.boot.credentials=.credentials
Adding the path to this credentials file to an environment variable : $SBT_CREDENTIALS = PATH
Adding the following line in the build.sbt : credentials += Credentials(new File(".credentials"))
Adding the following line in the build.sbt : credentials += Credentials("Sonatype Nexus Repository Manager", "nexus3.company.com", "xxxxx", "xxxxxx")
Checking what's going on with a proxy : my requests don't seem to have any authorization header and all come back as HTTP 401
And yet, when I access the URL mentioned from the same machine, with the credentials in the file, there is no issue at all.
I'm running out of ideas here :(
After more attempts, adding :
~/.sbt/1.0/credentials.sbt
credentials += Credentials("Sonatype Nexus Repository Manager", "nexus3.company.com", USER, PWD)
AND
The SBT_CREDENTIALS variable mentioned above,
Seems to do the job.
I also updated the image we use for our pipelines, not sure if it helped.
I am setting up Nexus3 repository as a remote repository in Artifactory.
But when I update the Nexus3 repo URL(https://domainname/repository/reponame/) & necessary credentials for authentication in the admin section, during testing i am getting,
Connection failed: Error 404.
I have tried providing the rest URL(http://domainname/service/rest/repository/browse/reponame).
In this case, connection to the nexus server establishes successfully & able to see the directory structure for the remote repo in the Artifacts section , but could not find the artifacts inside & seeing below output/error,
{ "errors" : [ {
"status" : 404,
"message" : "Couldn't find item: XXXX:XXXXXXX" } ]
You have to ignore the error while saving. This is because of a header mismatch.
Repo path should be like:
https://<host>:<port>/repository/reponame
Once you save the repository and try to download, it will work.
The test is failing when creating an Artifactory remote repository which point to a hosted Nexus repository, since Artifactory is using a HEAD request for checking the remote repository and for some reason Nexus will return a 404 (while returning a 200 when the same request is sent using the GET method). This behavior does not happen with Nexus group repositories.
I'm using Artifactory OSS 4.1.0 and Java 1.8.0_51.
When I try to download one of my local artifacts from the Artifactory web interface, I get this:
{
"errors" : [ {
"status" : 500,
"message" : "Could not process download request: Binary provider has no content for 'bab1c4e18f6c5edfb65b2503a388dea2fed0deb8'"
} ]
}
But I found this file in my Artifactory data area: ./files/ba/bab1c4e18f6c5edfb65b2503a388dea2fed0deb8, and upon further inspection it is the WAR file I tried to download.
I've come across other people on the web with the same error message, but their issue was with caching external artifacts, and their workaround was to delete the cache.
Does anyone have an idea what's going on and how I can fix the problem? BTW, I did stop and restart our Artifactory server, but with no noticeable difference.
Artifactory doesn't store the binaries under ./files directory, but under $ARTIFACTORY_HOME/data/filestore.
It looks like you had a symbolic link from the files directory to the filestore directory and this link was deleted.
I am facing a problem with Artifactory v3.9.5 resolving artifacts. I have the following setup:
local repository called "gradle-snaphot" allowed for snapshots
virtual repository called "repos" that includes "gradle-snapshot"
an artifact X uploaded to "gradle-snapshot"
Now, when I try to get the artifact directly, it works fine (credantials passed but omitted here):
wget http://myrepo/artifactory/gradle-snapshot/x/SNAPSHOT/maven-metadata.xml?trace
But when I try to get the artifact via the virtual repository, then it doesn't work:
wget http://myrepo/artifactory/repos/x/SNAPSHOT/maven-metadata.xml?trace
wget output is:
Resolving myrepo... xx.xxx.xxx.xx
Connecting to myrepo|xx.xxx.xxx.xx|:80... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: http://myrepo/artifactory/repos/x/SNAPSHOT/maven-metadata.xml/ [following]
--2015-12-11 11:17:18-- http://myrepo/artifactory/repos/x/SNAPSHOT/maven-metadata.xml/
Reusing existing connection to myrepo:80.
HTTP request sent, awaiting response... 404 Not Found
2015-12-11 11:17:18 ERROR 404: Not Found.
Artifactory is just returning 302 moved temporarily to the same URL with a slash added like a directory notation. Any idea why accessing virtual repository is not possible this way? In consequence, my Gradle build cannot resolve this dependency.
The root cause of this issue is the remote repository pointing at http://mirrors.ibiblio.org/pub/mirrors/maven2.
All requests to this repository will be redirected to http://maven.ibiblio.org/maven2/ no matter which path you are using and more important whether the requested resource exists.
The result is that when requesting an artifact from the virtual repository, at a certain point Artifactory will try to fetch the artifact from this remote repository and will get a 302 answer which redirects to the root of the repository. Artifactory assumes it got the resource it was looking for (got a 200 response code), however the returned resource is a folder and hence the additional / at the end of the URL.
The best solution would be just removing this remote repository and relying on JCenter.
If you do need it, use the http://maven.ibiblio.org/maven2/ URL which will save the redirects.
I followed the upgrade notes to upgrade from Artifactory 2.6.6 to 3.4.2, I reimported the artifacts but after that, artifact resolution often fails with 404.
Even previously deployed artifacts can not be resolved. The deploying Jenkins job runs fine, but when I open the URL from the log, I get that message:
{
"errors" : [ {
"status" : 404,
"message" : "Artifact not found: my/group/myapp/0.9.13-SNAPSHOT/myapp-0.9.13-SNAPSHOT.pom"
} ]
}
I also tried to export/import the whole system after upgrade, but nothing changed.
Does anyone know how to fix this?
I found out that the issue is related to the unique snapshot behaviour of Maven 3. In fact, there is no myapp-0.9.13-SNAPSHOT.pom, but one with a timestamp. The Rest API does not cover that and not all Jenkins plugins have support for that.