Using JFrog CLI (v1.48.1) I want to download the contents of a folder from an on-premise Artifactory instance (EnterpriseX license 7.41.7). The folder in question is on a specific sub-path in the Artifactory repo and has a specific property by which I can identify the folder.
The overall repo structure is a follows:
product-repo
|-- develop
`-- releases
|-- ProductX
`-- ProductY
|-- build01 [#release_ready = false]
|-- build02 [#release_ready = false]
`-- build03 [#release_ready = true]
|-- x86
| `-- program.exe
|-- x64
| `-- program64.exe
`-- common
`-- README.txt
All buildXX folders are identical in terms of content. All buildXX folders have a property named release_ready which is true for build03 and false for the other two folders.
In the example above, I want to download the folder build03 including all its contents because this folder is on the releases/ProductY path of the product-repo repository and has release_ready = true.
I have devised a file spec for this task:
{
"files": [
{
"aql": {
"items.find": {
"repo": "product-repo",
"path": {"$match":"*releases/ProductY*"},
"type": "folder",
"#release_ready": {"$eq": "True"}
}
},
"recursive": "true",
"target": "some/folder/on/my/disk/"
}
]
}
Using JFrog CLI to search this folder (jfrog rt s --spec myfilespec.json) works like a charm - as expected, Jfrog returns the folder build03.
However, when I try to download the folder using
jfrog rt dl --spec myfilespec.json Jfrog CLI only creates the folder structure releases/ProductY/build03 at the target path but never actually downloads any files. The exact log output is as follows:
Log path: C:\Users\myuser\.jfrog\logs\jfrog-cli.<date>.log
{
"status": "success",
"totals": {
"success": 0,
"failure": 0
}
}
With the log file containing just the following lines:
[Info] Searching items to download...
[Info] [Thread 2] Downloading procduct-repo/repeases/ProgramY/build03/
[Info] [Thread 2] Creating folder: releases\ProgramY\build03
What am I missing?
So, from above explanation, it gives a clarification that you have the property and value applied on a the folder only but not on the artifacts under it.
Your first AQL query results only the folder name.
Since it reveles the folder name, would it be feasible to pass the above result in the download command as below.
jfrog rt dl "product-repo/releases/ProductY/build3/*" --flat=false /some/folder/on/my/disk/
Try removing the "type": "folder" line from the spec file. I suspect this is what causing only the folder to be created but the actual files not to be downloaded.
You may also avoid using AQL, and use the "pattern" and "props" fields, making the spec file a bit more straight forward:
{
"files": [
{
"pattern": "product-repo/releases/ProductY*",
"props": "release_ready=true",
"recursive": "true",
"target": "some/folder/on/my/disk/"
}
]
}
Related
This is what my setup looks like:
JFrog CLI 1.26.2
I have a local directory with the following items:
spec (JFrog Upload Spec)
myartifact/1.0.0/myartifact-1.0.0-1.txt
My spec looks like so this:
{
"files": [
{
"pattern": "myartifact/*",
"regexp": "false",
"target": "testrepo-release/testbuilds/",
"recursive": "true",
"flat": "false",
"explode": "false"
}
]
}
Then I run build-add-dependencies:
shell>jfrog rt build-add-dependencies --spec=spec myartifact 1
[Info] Running Build Add Dependencies command...
[Info] Adding dependency: myartifact/1.0.0/myartifact-1.0.0-1.txt
{
"status": "success",
"totals": {
"success": 1,
"failure": 0
}
}
Finally I run build publish:
shell>jfrog rt build-publish --url=https://server.com/artifactory/ --user=user --password=password --build-url=https://fake myartifact 1
[Info] Deploying build info...
[Info] Build info successfully deployed. Browse it in Artifactory under https://server.com/artifactory/webapp/builds/myartifact/1
I can't figure out why there is nothing (builds or artifacts) at the target testrepo-release/testbuilds/
Thanks for your help!
The build-add-dependencies command collects files located on the local file-system and adds them as dependencies to the build-info. It does not upload the files to Artifactory.
In order to upload files, you first need to upload the files to Artifactory using the upload command. You can use the same file soec.
Omce the files are uploaded, you can then use the build-add-depedencies command to add the files as dependencies to the build.
Notice that the build-add-depedencies collects the files from the local file-system and not from Artifactory. Future releases of JFrog CLI may add the functionality of also collecting files from Artifactory and adding them to the build as dependencies (the latest release of JFrog when adding this answer is 1.27.0).
Something else to notice:
Both the upload and download commands accept two optional flags: --build-name and --build-number. These flags make the command register the uploaded files as build artifacts and the downloaded files as build dependencies.
I cannot get VS Code to build an empty class library while dotnet core can quite happily.
In PowerShell I create a folder called CoreTesting, navigate into it and launch VS Code with code.
I hit CTRL + ` to enter the terminal and navigate into the solution's folder.
I then enter dotnet new classlib --name Common, see the new folder Common and enter dotnet build .\Common\ to build the class library. All is well.
I add the Common folder to VS Code and hit CTRL + SHIFT + B and see No build task to run found. Configure Build Task..., so I hit return and see Create tasks.json file from template, so I hit return again and see:
MSBuild
maven
.NET Core
Others
So I select .NET Core and see that a .vscode folder is created containing tasks.json. This file contains:
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"tasks": [
{
"label": "build",
"command": "dotnet build",
"type": "shell",
"group": "build",
"presentation": {
"reveal": "silent"
},
"problemMatcher": "$msCompile"
}
]
}
I hit CTRL + SHIFT + B again and see the option build Common, so I hit return and see this:
> Executing task in folder Common: dotnet build <
Microsoft (R) Build Engine version 16.0.225-preview+g5ebeba52a1 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.
MSBUILD : error MSB1003: Specify a project or solution file. The current working directory does not contain a project or solution file.
The terminal process terminated with exit code: 1
Terminal will be reused by tasks, press any key to close it.
The structure I can see is this:
Common\
.vscode\
tasks.json
bin\
obj\
Class1.cs
Common.csproj
What have I done wrong?
I was able to reproduce your problem on v1.41.1 for Windows. In doing so it created this tasks.json which is similar to yours...
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"tasks": [
{
"label": "build",
"command": "dotnet",
"type": "shell",
"args": [
"build",
// Ask dotnet build to generate full paths for file names.
"/property:GenerateFullPaths=true",
// Do not generate summary otherwise it leads to duplicate errors in Problems panel
"/consoleloggerparameters:NoSummary"
],
"group": "build",
"presentation": {
"reveal": "silent"
},
"problemMatcher": "$msCompile"
}
]
}
When you invoke a task, it defaults to using the workspace folder (CoreTesting) path as the working directory. However, the project file is a directory beneath in Common, hence the error The current working directory does not contain a project or solution file.
A quick fix for this is to simply open the directory with the project file as the workspace folder (i.e. File → Open Folder... → Select the Common directory).
Alternatively, if that solution is undesirable then with CoreTesting opened as the workspace folder you can configure the task to execute with a different working directory. To do this, set the task's options.cwd property...
{
/* snip */
"tasks": [
{
/* snip */
"problemMatcher": "$msCompile",
"options": {
"cwd": "${workspaceFolder}/Common"
}
}
]
}
I found this property in the Schema for tasks.json, and it's also mentioned in the Custom tasks section of the Tasks documentation. After making either change above the library builds successfully for me.
I have set up my mesos cluser correctly with one master and two slaves. What I am trying to do is use the mesos-execute framework to run jar files on the cluster. I can use it to run simple commands like:
mesos-execute --master=mesosr:5050 --name="simple-test" --command=echo "hello"
Which will run as expected. However if I try to replace that echo "hello" command with something like "java -jar helloWorld.jar" it won't work.
I managed to identify the problem, but I don't know how to fix it. The issue is that the command doesn't run from the home directory, it runs from something similar to this
/var/lib/mesos/slaves/3f5439b1-7fab-45d6-876e-7e75b7c15fc9-S0/frameworks/3f5439b1-7fab-45d6-876e-7e75b7c15fc9-0043/executors/java-test/runs/7c20baff-080f-48ee-95fc-3662c388744b
I got that path by running "pwd" as a command on mesos-execute.
Now, my question is how do I get out from there? cd doesn't work.
Is there any way for me to get to the home folder or to a special folder where I can put my jars to make them accessible to mesos-execute?
The use case for this application is that there will be a lot of small jar files that will have to be run on the cluster. They don't have to stay alive, so I am not using anything like Marathon for these jars.
Thank you.
From mesos-execute -h
--task_group=VALUE The value could be a JSON-formatted string of TaskGroupInfo or a file path containing the JSON-formatted TaskGroupInfo. Path must be of the form file:///path/to/file or /path/to/file. See the TaskGroupInfo message in mesos.proto for the expected format. NOTE: agent_id need not to be set.
Example:
{
"tasks":
[
{
"name": "Name of the task",
"task_id": {"value" : "Id of the task"},
"agent_id": {"value" : ""},
"resources": [{
"name": "cpus",
"type": "SCALAR",
"scalar": {
"value": 0.1
}
},
{
"name": "mem",
"type": "SCALAR",
"scalar": {
"value": 32
}
}],
"command": {
"value": "sleep 1000"
}
}
]
}
What interest you most is command part. There you can define your task with all files it need to download to run correctly. All possible configuration options for command are specified in CommandInfo.
Ok, so I figured out how to do it.
I was going about it all wrong, perhaps not the best idea to tackle a new thing at the end of a workday.
What I was trying to do was change directory to the home directory as part of the mesos-execute command. This is not allowed. The way to run a jar that is located in the home directory is to specify the path of the jar in the java -jar command. So the final command, that works, looks like this:
mesos-execute --master=mesosr:5050 --name="simple-test" --command="java -jar /home/user/jarFile.jar"
This works, and the jar is executed on the cluster.
I have some artifacts in Artifactory (OpenSource):
I can download an artifact from using jfrog CLI:
jfrog rt config --user=admin --password=**** --url=http://foo:8081/artifactory
jfrog rt download testproject/01_Develop/01_CI/HPCC-Package-70.zip --flat=true
How can I download the LATEST(highest number) artifact?
JFrog CLI recently started supporting 3 new options from many of the Artifactory commands: --sort-by --sort-order and --limit.
You can use these options to search, download, copy, move or delete the latest artifact created in Artifactory. For example, to download the latest file uploaded to the all-my-frogs folder in the my-local-repo repository, use the following command:
jfrog rt dl "my-local-repo/all-my-frogs/" --sort-by=created
--sort-order=desc --limit=1
You can use the JFrog Cli search command.
jfrog rt s "testproject/01_Develop/01_CI/HPCC-Package-*.zip"
The search command will return a list of paths which you can then sort using external tools such as jq.
If you wish to do it from a Jenkins groovy file, you could use:
def downloadSpec = """{
"files": [
{
"pattern": pattern,
"target": "",
"flat" : "true",
"sortBy": ["name"],
"sortOrder": "desc",
"limit": 1
}
]
}"""
I have a firebase app with the following hosting configuration:
{
"firebase": "the-world-table",
"public": "app",
"ignore": [
"firebase.json",
"**.*",
"**/node_modules/**"
]
}
The app directory is not empty (it has an index.html and a javascript file in it). However, when I deploy I get the following warning:
Preparing to deploy Public Directory...
Public Directory Warning - Public directory is empty, removing site
progress: 100%
Sucessfully removed
And when I browse to the static files, they aren't found. Any ideas what is wrong here?
Your ignore rules appear to be a little over zealous in removing files from the directory you specified to be deployed:
Instead of the default **/.* ignore rule which matches all files in any sub-folder that contain a . character, the rule you specify **.* matches all files in the root of the folder to be deployed that contains a ., which in this case caused nothing to remain. If you remove this line or add the / back in you should see the behavior you expect.
The docs on the subject cover the basics of glob pattern matching and offer some further references
firebase is looking by default in folder public for file index.html.
if in angular4 for example the index.html exists in folder dist you have to go into firebase.json and paste there:
{
"hosting": {
"public": "dist"
}
}
this is direct the firebase to look for index.html in dist folder or whatever is folder call instead public.
of cores you have that your file call index.html.
after that:
firebase deploy
probably will work
It looks like you're trying to deploy an empty directory.
The public property should correspond to where your public files, like index.html reside.
There are a couple of ways to fix it:
1. Change the config to point to your public content
Change firebase.json to point to the correct location. For example, if your html files are in the same directory as firebase.json, your config might look like this:
{
"firebase": "the-world-table",
"public": ".",
"ignore": [
"firebase.json",
"**.*",
"**/node_modules/**"
]
}
2. Make the directory structure match your config
Here's an example directory structure that would work with your firebase.json config:
- project/
- README.md
- firebase.json
- app/
- index.html
Change the below code in your firebase.json if you your index.html is in a public folder
{
"hosting": {
"public": "./"
}
}
Looks like my firebase.json discovered a bug in firebase-tools. The files specified in the "ignore" section are treated as though they were relative to the directory specified in "public". If you specify non-existent files in your "ignore" section, it will halt before even beginning the deployment and give an error like the one above.