We are using jfrog-cli to upload the build artifact to Artifactory.
Once it's uploaded, I would like to add/update the build artifact properties.
I'm using following command:
jfrog rt sp "<artifactory_server>/<repo>/<version>/*.zip" "Build1=test1"
It returns as follows:
[Debug] Artifactory response: 200 OK
[Info] Setting properties...
[Info] Done setting properties.
{
"status": "success",
"totals": {
"success": 0,
"failure": 0
}
}
It looks like you added your artifactory_server to the path.
You should run the following instead:
jfrog rt sp "<repo>/<version>/*.zip" "Build1=test1"
In addition, if you manage several Artifactory instances through JFrog CLI you could point to the specific Artifactory instance by using the --server-id flag as the following:
jfrog rt sp "<repo>/<version>/*.zip" "Build1=test1" --server-id=my_artifactory
Related
We were trying to Integrate Xray with our Jfrog Artifactory. In Amazon Linux 2 we are trying to install with docker compose,while we run the config.sh
After running the bellow docker compose commands
start rabbitmq: docker-compose -p xray-rabbitmq -f docker-compose-rabbitmq.yaml up -d
start postgresql: docker-compose -p xray-postgres -f docker-compose-postgres.yaml up -d
start: docker-compose -p xray up -d
xray router is getting restarting after 20sec with following error:
We have checked whether any selinux, firewalld, or iptables are blocking,but all are in disable state.
Can someone help us to resolve the issue?
Now Private IP is able to reach Artifactory server,we have created Xray in same VPC of Artifactory.
Now all containers of Xray are running in Xray server,but now we have a different issue.
In xray server container we are getting the below logs
2021-08-12T13:41:17.601Z [jfxr ] [INFO ] [469946e5f04dd2c6] [updates_service:486 ] [main ] Initializing JFrog vendor
2021-08-12T13:41:17.700Z [jfxr ] [ERROR] [ ] [bin_mgr_cache:50 ] [main ] Failed to get binary managerid:failed on GetAllBinaryManagerIds query
--- at /go/src/jfrog.com/xray/internal/dbaccess/dao/binary_managers_dao.go:367 (binMgrDao.GetBinaryManagerId) ---
Caused by: not found
2021-08-12T13:41:17.701Z [jfxr ] [ERROR] [ ] [bin_mgr_cache:59 ] [main ] Failed to get binary manager'' version, err :failed to fetch binary manager
--- at /go/src/jfrog.com/xray/internal/dbaccess/dao/binary_managers_dao.go:290 (binMgrDao.GetBinMgrByID) ---
Caused by: not found
2021-08-12T13:41:17.701Z [jfxr ] [WARN ] [ ] [indexed_resources_cache:36 ] [main ] Failed to get binary managerfor cache:failed to fetch binary manager
--- at /go/src/jfrog.com/xray/internal/dbaccess/dao/binary_managers_dao.go:290 (binMgrDao.GetBinMgrByID) ---
Caused by: not found
Any idea on this?
#praseeb It appears you are giving JFrogURL as the node IP of xray. It should be the reachable URL of artifactory from the xray machine, Please pick it from Admin > Security > Settings as indicated.
I had similar issue with some custom Docker Compose files.
It was a network issue, the containers (server, indexer, analysis, persist) did not start in the same network as the router. This occurs because I use docker-compose [...] --no-start.
With the --no-start option, the network_mode: service:router was ignored and the containers goes to the default bridge network. So they cannot communicate with the router on local ports (8046, etc).
I have created an AQL that gives me a number of artifacts I want to delete from Artifactory. I can run a search command with the jfrog-cli on it, and get the correct list of artifacts:
jfrog rt s --spec search-aql.json
When I try to delete the same artifacts with the same AQL, everything seems fine:
The artifacts are listed
I get a questions of whether to delete them or not.
I answer yes, and the command goes on to log the deletion of each item.
Each item seems to be returned and printed to my console, followed by this message:
[Error] Artifactory response: 200 OK
Binaries are also printed to the console, so the console output is really messy.
In the end, I get a summary:
{
"status": "failure",
"totals": {
"success": 0,
"failure": 68
}
}
[Error] Artifactory response: 200 OK
With the same user, I can delete individual artifacts using the REST API, so the user does have the necessary rights to do deletion.
I am on version 1.38.2 of the JFrog CLI and 7.2.1 of Artifactory.
Can anybody help me understand what is wrong or how to debug this problem?
Update 2020/08/06:
When setting the log level to debug as suggested by #Prostagma, I get two extra lines of logging for each artifact. Here is an example of logging for two artifacts:
[Info] [Thread 1] Deleting <path>/<artifact>.jar.sha512
[Debug] Sending HTTP DELETE request to: https://repo.enonic.com/<path>/<artifact>.jar.sha512
[Error] Artifactory response: 200 OK
<sha512 hash>
[Info] [Thread 0] Deleting <path>/<artifact>.jar
[Debug] Sending HTTP DELETE request to: https://repo.enonic.com/<path>/<artifact>.jar
[Error] Artifactory response: 200 OK
<binary contents of <artifact>.jar
More detailed answer to whomever encounter this issue in the future -
By diving into the code we can see that the CLI expects to get status 204 from Artifactory after deletion:
https://github.com/jfrog/jfrog-client-go/blob/v0.12.0/artifactory/services/delete.go#L110
In some installations, there may be a proxy that changes the response codes, for example when Artifactory returns 204, it may change the status code to 200.
Please make sure that your proxy doesn't change the status codes returned from Artifactory.
I am using an Artifactory server. I am trying to store a folder of third party files in my repo.
I was able to upload a zipfile and explode it so I have my files in MY_REPO/MY_FOLDER/
I am trying to recursively download the contents of the folder using:
jfrog rt dl --recursive MY_REPO/MY_FOLDER
I have enabled debug and I get:
[Info] Searching items to download...
[Debug] Searching Artifactory using AQL query:
items.find({"repo": "MY_REPO","path": {"$ne": "."},"$or": [{"$and":[{"path": {"$match": "MY_FOLDER"},"name": {"$match": "*"}}]},{"$and":[{"path": {"$match": "MY_FOLDER/*"},"name": {"$match": "*"}}]}]}).include("name","repo","path","actual_md5","actual_sha1","size","type","property")
[Error] Artifactory response: 405 Method Not Allowed
{
"status": "failure",
"totals": {
"success": 0,
"failure": 0
}
}
[Error] Download finished with errors. Please review the logs
I have tried variations of MY_FOLDER, MY_FOLDER/, MY_FOLDER/. and with/without recursive. I get the same error.
I know I have permissions because I can upload a file:
jfrog rt u TEST_FILE MY_FOLDER
succeeds just fine. But I can't turn around and pull it down:
jfrog rt dl MY_FOLDER/TEST_FILE
results in:
[Info] Searching items to download...
[Debug] Searching Artifactory using AQL query:
items.find({"repo": "MY_REPO","$or": [{"$and":[{"path": {"$match": "."},"name": {"$match": "MY_FILE"}}]}]}).include("name","repo","path","actual_md5","actual_sha1","size","type","property")
[Error] Artifactory response: 405 Method Not Allowed
{
"status": "failure",
"totals": {
"success": 0,
"failure": 0
}
}
[Error] Download finished with errors. Please review the logs
I'm not certain what isn't working, there's nothing on StackOverflow, JFrog dox or elsewhere with issues using jfrog cli. :(
My jfrog-cli.conf looks like this:
{
"artifactory": [
{
"url": "https://SITE_NAME:PORT_NUM/artifactory/list/MY_REPO/",
"user": "USERNAME",
"serverId": "MY_REPO",
"isDefault": true,
"apiKey": "API_KEY_FROM_ARTIFACTORY"
}
],
"Version": "1"
}
UPDATED
I was running version 1.22.1 for Windows 64-bit. I am now using jfrog cli version 1.34.1 for Windows 64-bit. Per first comment I updated to the latest binary and tried running a search, both with and without MY_FOLDER:
jfrog rt s TEST_FILE and
jfrog rt s MY_FOLDER/TEST_FILE
Both return the same results. I enabled DEBUG and with the newer binary I actually seem to get two errors. The older binary just reported the 405 error. The newer one reports a 404 (Not Found) then reports the error as a 405 Method Not Allowed.
[Debug] Sending usage info...
[Info] Searching artifacts...
[Debug] Searching Artifactory using AQL query:
items.find({"$or":[{"$and":[{"repo":"TEST_FILE","path":{"$match":"*"},"name":{"$match":"*"}}]}]}).include("name","repo","path","actual_md5","actual_sha1","size","type","modified","created","property")
[Debug] Sending HTTP POST request to: https://SITE_NAME:8443/artifactory/list/MY_REPO/api/search/aql
[Debug] Sending HTTP GET request to: https://SITE_NAME:8443/artifactory/list/MY_REPO/api/system/version
[Debug] Artifactory response: 404 Not Found
{
"errors": [
{
"status": 404,
"message": "File not found."
}
]
}
[Error] Artifactory response: 405 Method Not Allowed
Which is still odd because I'm looking for a file I just uploaded. I even deleted the uploaded file and re-uploaded to verify the newer cli can still upload files. I tried a wildcard search to find all files but it returned the same error.
I can also see the file where it is supposed to be using the Artifactory web interface, and download the file and delete it. So Artifactory knows it's there and I have access to it. :-/
The url in your configuration should only contain the base url of Artifactory, i.e: "SITE_NAME:PORT_NUM/artifactory".
You should provide the directory path in the upload and download commands.
Use the ping command to verify your setup works, then progress from there.
BTW: The reason the upload works but download fails is by coincidence. The upload command just uses the upload REST API which expects a path (which you provided in your config), but the download command first sends a search request that does not expect a path, so it fails.
I am using the jfrog CLI.
I use the same values for "rt" : config, upload, search.
But it breaks when I try a "delete".
It partially works in that it finds the file for a delete when it looks it up, but when it tries to delete the file object, it adds a REPO: /path and then errors.
Any ideas as to why it uses a "REPO: /path" versus "repo/path"?
Search finds it with the "repo/path"?
Code:
jfrog rt delete --user=xxxx --password=##### -url=https://server.domain/artifactory REPO_NAME/dir/dir/dir/dir/file.rpm
Get:
[Info] Searching artifacts...
[Info] Found 1 artifact.
AXONE-YUM/soup/axone-layer-zero/CentOS/matt/GeoIP-1.5.0-11.el7.x86_64.rpm
Are you sure you want to delete the above paths? (y/n): y
[Info] Deleting: AXONE-YUM/soup/axone-layer-zero/CentOS/matt/GeoIP-1.5.0-11.el7.x86_64.rpm
[Error] Artifactory response: 404 Not Found
{
"errors": [
{
"status": 404,
"message": "Could not locate artifact 'AXONE-YUM:soup/axone-layer-zero/CentOS/matt/GeoIP-1.5.0-11.el7.x86_64.rpm'."
}
]
}
{
"status": "failure",
"totals": {
"success": 0,
"failure": 1
}
}
install jfrog CLI
Add proper certificate to .jrog folder
Run below:
jfrog rt c
#Enter server url
#API Key: blank
user ID
Password
Now it encrypts password. You are ready to go.
Try
jfrog rt del repo path/version/ --quiet=true
(no need of full url, straight from repo)
I have https://packages.cloud.google.com/yum configured as a remote repo in Artifactory.
My repo file on Centos 7.3 looks like this:
[kubernetes]
name=kubernetes
baseurl=https://artifactory.company.com/artifactory/packages.cloud.google.com-yum/repos/kubernetes-el7-x86_64/
enabled=1
gpgcheck=1
When I run yum install -y kubelet it prints this error:
e7a4403227dd24036f3b0615663a37 FAILED
https://artifactory.company.com/artifactory/packages.cloud.google.com-yum/repos/kubernetes-el7-x86_64/../../pool/e7a4403227dd24036f3b0615663a371c4e07a95be5fee53505e647fd8ae58aa6-kubernetes-cni-0.5.1-0.x86_64.rpm: [Errno 14] HTTPS Error 500 - Internal Server Error
Trying other mirror.
I am pretty sure the problem is the relative path in the URL: kubernetes-el7-x86_64/../../pool
If I wget the URL it works fine because wget is resolving out the relative path before sending the HTTP request, but yum does not do this and Artifactory returns a 500 when you give it a url with ../ in it. Does anyone know how to enable relative URLs in Artifactory? Or how to get yum to resolve URLs before sending the requests?
I am running these versions:
Artifactory 5.2.0
Yum 3.4.3-150
Update: This is the HTTP response body from artifactory:
{
"errors" : [ {
"status" : 500,
"message" : "Could not process download request: Path element cannot end with a dot: packages.cloud.google.com-yum-cache/repos/kubernetes-el7-x86_64/../"
} ]
}
The remote repository should be set with the following url in Artifactory
https://packages.cloud.google.com/yum/
The baseurl on the yum client should point on the repodata folder with the following:
baseurl=http://artifactory.company.com/artifactory/yum-remote/repos/kubernetes-el7-x86_64/
(The name of the remote repository is 'yum remote')
This should work without any further configuration from the Artifactory side.
The error you have mentioned regardin the relative path 'kubernetes-el7-x86_64/../../pool' happens during the caching of the artifact.
Artifactory cannot cache to a path which contains the '..' pattern so the request is failing.
It can be solved from Artifactory side with a user plugin.
If the path contains the '..' pattern then the plugin will modify the path where the artifact will cached so it will not include this pattern.
This is now redundant as the registry retrieves paths which doesn't include '..' in them.