That seems a very intuitive step to do but I have a issue with that.We have a build that contains some archived files. Let’s say, we would like to promote it and copy the artifact saved in this build to some shared storage location. So we are using a promote plugin that is exactly what we need but there is NO option to use a "parent" job archived files. I tried to use "copy artifact from another project" but I cannot pass a build number of a "parent" build.
What do I miss?
P.S. We cannot use “Publish Over” plugin since it expose all Jenkins users our shared folders and enables all users to copy files there.
I'm not sure i understood right when you say
I tried to use "copy artifact from another project" but I cannot pass a build number of a "parent" build."
But possibly it could help, with these variables you can retrieve information from the parent job:
Retrieve build number or artifacts of downstream build in Jenkins
Moreover, you can try this one too: https://wiki.jenkins.io/display/JENKINS/Copy+Artifact+Plugin
It permit you to finger print artefact and than copy them, i used in the past and it works pretty good!
Hope it helps
Here I found a lead to my solution: Jenkins: Use Archived Artifact in Promoted Build
Within the "Copy Artifact Plugin":
Project name: "my parent job name" (somehow, ${PROMOTED_JOB_NAME} refuses to work)
Which build: Specific build
Build number: ${PROMOTED_NUMBER}
Artifact to copy: empty
Artifact not to copy: empty
Target directory: \\my_shared_folder\
Related
The question here indicates that when an ExePackage has DownloadUrl it also needs a copy of SourceFile.
We keep the copy of the Sql Server Setup in a separate Release folder that is not part of the development environment. We do this so our daily backup doesn't have to copy the same 300+MB every time.
However, when Burn builds our Setup, it copies the SourceFile to the output folder along with the .exe it creates. The filename is the DisplayName and the file is the same size as the file in the Release folder.
The result is similar to setting CopyLocal on a project reference.
Can I tell Burn not to copy this file on build?
Edit
I am deleting the file with the post-build event in Visual Studio. However, this doesn't answer the original question.
Further Information
After I delete the file and run the Setup, I get an error in the MSI log: Failed to resolve source for file.
This happens at run-time, and the file referenced is located in the project output folder. How is it possible that Burn is looking at the source file at run-time?
That question also mentioned that it if you provide the RemotePayload element, then it doesn't need the SourceFile. So use RemotePayload so that it never copies it.
I'm using FossilSCM as my only solution for control version and tickets. So far, so good. Its self contained and minimalist approach suit my needs. But I would like to start to make some analysis on the projects history and development and a good soruce for that are the projects timelines. I could go with some html parsing trying to convert the Fossil timeline output to something else, but I would like if there is any option to export that info in other structured format (e.g JSON or similar). Web search has not produce any useful finding on that issue. Any pointers to a solution?
Thanks,
Offray
Have you tried fossil json timeline branch trunk?
fossil help json
Usage: fossil json SUBCOMMAND ?OPTIONS?
In CLI mode, the -R REPO common option is supported. Due to limitations
in the argument dispatching code, any -FLAGS must come after the final
sub- (or subsub-) command.
The commands include:
anonymousPassword
artifact
branch
cap
config
diff
dir
g
login
logout
query
rebuild
report
resultCodes
stat
tag
timeline
user
version (alias: HAI)
whoami
wiki
Run 'fossil json' without any subcommand to see the full list (but be
aware that some listed might not yet be fully implemented).
Compile json when you build from source:
./configure --json
The key for having this working is to enable json support in fossil by compiling it from sources. Current version have it disabled, so looking for any clue on it in command line help got me nothing originally. Thanks to user 2612611 for the initial clue about it. Here is the procedure I followed:
Go to https://www.fossil-scm.org/download.html and download the source tarball package.
Uncompress the previous package.
Go to the folder where you uncompressed the package (lets call it /uncompress-folder
Run ./configure --json
Run make.
Optional: Put your newly created fossil binary in your path or where the last one was installed (something like sudo mv /uncompress-folder/fossil /usr/bin/fossil.
Open the fossil repository that you want to export its history and launch the fossil web interface (fossil ui).
Go to http://localhost:8080/json/timeline/checkin?limit=0 ,where http://localhost:8080 is your local machine interface for fossil ui, and json/timeline/checkin?limit=0 is the json API call saying: json export of timeline (/json/timeline) chekins (/checkin) for all history (?limit=0). If instead of the 0 at the end of the url you put another integer you will have the last n checkins.
From command prompt you should be able to get the same result by running fossil json timeline checkin --limit=0 > timeline.json stored on the file timeline.json, instead of the web browser but in local test it didn't work.
API is still a moving target, but you can find documentation on this excellent project at [1] and a demo interface to test the parameters at [2]
[1] https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/view?pli=1#
[2] http://fossil.wanderinghorse.net/repos/fossil-sgb/json/
I have the following files which I would like to upload to Artifactory as a 9.8.0 versioned artifact.
NOTE: The first two files DO NOT have an extension (they are executable files i.e. if you open them/cat on it, you'll see junk characters).
Folder/files of a given version 9.8.0 in CVS is like:
com.company.project/gigaproject/v9.8.0/linux/gigainstall
com.company.project/gigaproject/v9.8.0/solaris/gigainstall
com.company.project/gigaproject/v9.8.0/win32/gigainstall.exe
com.company.project/gigaproject/v9.8.0/gigafile.dtd
com.company.project/gigaproject/v9.8.0/gigaanotherfile.dtd
com.company.project/gigaproject/v9.8.0/giga.jar
com.company.project/gigaproject/v9.8.0/giga.war
Uploading the above files which have an extension is very easy... You log in to Artifactory as an administrator/user which has access to deploy artifacts, click on "Deploy" tab, browse for the Artifactory file and once you select the file, click on "Upload" button.
Next you'll see a screen (like shown above). You'll tweak what you want in the fields on this page and once you click on "Deploy Artifact", you are done. All you have to make sure is you select the correct file.extension file while uploading and make sure the file extension is shown in the "Target Path" box correctly (with the version -x.x.x, etc.).
My questions:
Question 1: How do I upload an artifact which doesn't have an extension? It seems like Artifactory by default takes an artifact as a .jar extension. How can I upload the "gigainstall" artifact as shown in the folder/file structure above for both Linux and Solaris? I see I can use the artifact name as gigainstall-linux and gigainstall-solaris and differentiate it, but I am not sure how to tell Artifactory that this artifact doesn't have any extension.
I don't think the development team will start generating this artifact with a proper extension (as this artifact may be hard coded everywhere in other projects where they are currently getting it from CVS/SVN source control somewhere - which is itself a bad practice to store an artifact in a source control version tool).
Question 2: How would I tell a build system (for example, Gradle) to consume a non-extensioned artifact during, let's say, 'compile' task. In build.gradle under section dependencies { .. }, I will add something like as shown below, but I am not sure for non-extensioned files (the first two in the folder/file structure I mentioned above).
dependencies {
//compile 'com.company.project:gigainstall-linux:9.8.0#'
//compile 'com.company.project:gigainstall-linux:9.8.0#??????'
//compile 'com.company.project:gigainstall-linux:9.8.0#""'
//compile 'com.company.project:gigainstall-linux:9.8.0#"none"'
//compile 'com.company.project:gigainstall-linux:9.8.0#"NULL_or_something"'
// The following will easily get giga.jar version giga-9.8.0.jar from Artifactory repository
compile 'com.company.project:giga:9.8.0'
// The following will easily get giga.war
compile 'com.company.project:giga:9.8.0#war'
// Similarly, other extension based artifacts can be fetched from Artifactory
compile 'com.company.project:gigafile:9.8.0#dtd'
compile 'com.company.project:gigaanotherfile:9.8.0#dtd'
}
Answer 1 (will cover 2 as well in a different sense): Using Artifactory "Artifact Bundle" feature section under "Deploy" tab can do the TRICK for AT LEAST uploading the artifacts in a way we want, by creating a zip file first (containing the structure and artifacts in it) --OR you can upload the artifacts using/calling Artifactory REST API way.
High level idea:
Create a zip file called gigaproject.zip OR anyname.zip/.tar/compressed file which Artifactory can read. Inside the zip, create the structure - how these artifacts will be loaded to Artifactory
i.e.
gigaproject.zip will contain the following folders/structure/files.
Case 1:
com/company/project/gigaproject/9.8.0/linux/gigainstall
com/company/project/gigaproject/9.8.0/solaris/gigainstall
com/company/project/gigaproject/9.8.0/win32/gigainstall.exe
com/company/project/gigaproject/9.8.0/gigafile.dtd
com/company/project/gigaproject/9.8.0/gigaanotherfile.dtd
com/company/project/gigaproject/9.8.0/giga.jar
com/company/project/gigaproject/9.8.0/giga.war
NOTE: In case 1 example, I didn't use any -x.x.x in the filename (i.e. I'm using plain and simple giga.jar instead of giga-9.8.0.jar).
The above Upload/Deploy will result the files (as shown in the following snapshot):
So, we have achieved what we wanted. Actually (visibly speaking yes), but not in a way Artifactory usually stores these artifacts (as they should -x.x.x version embedded in the file name and where artifact id should match the artifact filename). Now, if you want to consume the following in a Gradle build file, you CANNOT as first, you haven't uploaded the filename with -x.x.x version name in it, secondly, the artifact id in our case 1 tree was "gigaproject" (after com/company/project folder), so Gradle way of defining what artifact id and what artifact file name you want won't work.
compile 'com.company.project:gigaproject:CANNOTSAY_HOW_TO_GET_GIGA_JARorGIGAINSTALL_with_without_extension'
Conclusion: It's possible to upload any files (with/without extension in Artifactory) in any structure but it depends how your build system will consume it or will be able to consume it or not.
- I deleted the structure I just created with case 1 .zip file from Artifactory repository to try next case#2 and deleted the .zip file I created.
Case 2:
Let's create an individual versioned file name for each artifact and also create structure in the format - how Artifactory actually stores them (an artifact as seen in a repository in a tree view) and create a .zip file containing that structure. Let's use the same "Artifact Bundle" feature to upload this .zip file to upload individual artifacts that we need in Artifactory - where artifact-id (second value which we mention while trying to consume it) would match the artifactfile name in Artifactory.
Folder/file structure for the .zip file:
com/company/project/gigainstall/9.8.0/gigainstall-9.8.0.linux
com/company/project/gigainstall/9.8.0/gigainstall-9.8.0.solaris
com/company/project/gigainstall/9.8.0/gigainstall-9.8.0.exe
com/company/project/gigafile/9.8.0/gigafile-9.8.0.dtd
com/company/project/gigaanotherfile/9.8.0/gigaanotherfile-9.8.0.dtd
com/company/project/giga/9.8.0/giga-9.8.0.jar
com/company/project/giga/9.8.0/giga-9.8.0.war
NOTE: This time, we'll be using the same "Artifact Bundle" feature and for similar files (gigainstall under both Linux/Solaris folders), I took the approach of creating gigainstall folder (containing gigainstall-9.8.0.linux and gigainstall-9.8.0.solaris file names) i.e. when we'll consume these artifacts in Gradle under dependencies { ... } section for compile, we'll use x.x.x# way to fetch these artifacts from Artifactory.
OK, once "Artifact Bundle" Deploy/Upload was successfully complete, I got the following message.
Successfully deployed 7 artifacts from archive: gigaproject.zip (1 seconds).
Now, let's see how it looks like in Artifactory while searching for one of the artifact/in Tree view. You can see we have the files now in place, with filename-x.x.x.extension way so that I can consume them easily in Gradle.
In Gradle build file (build.gradle), I'll mention:
dependencies {
compile "com.company.project:gigainstall:9.8.0#linux"
compile "com.company.project:gigainstall:9.8.0#solaris"
compile "com.company.project:gigainstall:9.8.0#linux"
compile "com.company.project:giga:9.8.0
compile "com.company.project:giga:9.8.0#war
compile "com.company.project:gigafile:9.8.0#dtd
compile "com.company.project:gigaanotherfile:9.8.0#dtd
}
OH OH!! - That didn't work, see below for Gradle error. Why? - Artifactory Bundle upload/deploy feature uploads a zip file content what you have in the .zip but it DOES NOT create a .pom file per artifact it deploys. Thus, making the Gradle build to fail. May be in Ant this might succeed. This occurred for each individual .jar/.war/.dtd/etc file. I'm just showing one error example.
While doing gradle clean build
Could not resolve all dependencies for configuration ':compile'.
> Could not resolve com.company.project:gigafile:0.0.0.
Required by:
com.company.project:ABCProjectWhichConsumesGIGAProjectArtifacts:1.64.0
> Could not GET 'http://artifactoryserver:8081/artifactory/ext-snapshot-local/com/company/project/gigafile/0.0.0/gigafile-0.0.0.pom'. Received status code 409 from server: Conflict
Case 3: Let's take a simple approach (workaround but will save a lot of pain).
Create gigaproject.zip file with the following structure, this approach takes - No x.x.x version value embedded in the individual artifact/filename in the folder/file structure. We will use "Single Artifact" approach (which will create the .pom for gigaproject.zip file automatically during the upload/deploy process provided by Artifactory). You'll still be able to get gigainstall file without needing any extension to its name using this approach. During the upload/deploy step, as you already have seen, you upload gigaproject.zip and artifactory will upload it to a given Target Repository as "gigaproject-x.x.x.zip" where x.x.x is 9.8.0 in our case. See the image snapshot below.
gigaproject/linux/gigainstall
gigaproject/solaris/gigainstall
gigaproject/win32/gigainstall.exe
gigaproject/gigafile.dtd
gigaproject/gigaanotherfile.dtd
gigaproject/gigaproject.zip
gigaproject/giga.jar
gigaproject/giga.war
Now, upload it in Artifactory using "Single Artifact" feature. Click "Deploy Artifact" once you tweak the values for GroupId, ArtifactId, Version, etc.
Once this is uploaded. You'll see in the zip artifact in the target repository (I took a bad example, usually this would be libs-snapshot-local or libs-release-local instead of ext-...), you'll be able to consume the ZIP artifact directly in Graddle:
dependencies {
// This is the only line we need now.
compile "com.company.project:gigaproject:9.8.0#zip"
}
Once the .zip is available to Gradle build system, now you can tell Gradle to unpack this .zip file somewhere in your build/workspace area where you can feed the actual(unpacked) files (gigainstall, .dtd, .jar, .war, etc.) to the build process/steps.
PS: Case# 1 and 2 would have worked for Ant I guess.
Answer 2:
If you have uploaded a non-extensioned file in either way. Make sure you have manually created/uploaded its POM file as well (i.e. if I uploaded gigainstall-9.8.0 as an artifact under com/company/project/gigainstall/9.8.0/gigainstall-9.8.0, then at the same level, I have to/should create it's POM file (see a simple template .pom file for a custom jar artifact or while uploading an extensioned file via "Single Artifact" deploy, you'll see what POM Editor window shows you) and upload both so that Gradle won't error out saying no POM conflict/error. Ant might not need pom (I didn't check that).
Once it's there in Artifactory, the following line should work -- OR comment please if you find another way.
dependencies {
// See nothing mentioned after - x.x.x#
compile "com.company.package:gigainstall:9.8.0#"
}
I know there's a lot of information on here about installing python packages, but I'm quite new to python and I think I need a more "for dummies" level of help.
I was trying to install openpyxl for which as far as I can tell I need easy_install, for which, as far as I can tell, I need setuptools. I tried running the code provided here https://pypi.python.org/pypi/setuptools which is supposed to download and install setuptools (and according to some sites, easy_install aswell?) - it runs successfully, but help(modules) doesn't show setuptools or easy_install as modules, I have no idea whats installed and what isn't, or how I'm supposed to install any of it!
Essentially I'm very confused, very frustrated and really need someone to talk me through (in idiot-speak) what I'm supposed to do.
Thankyou!
We all start somewhere, I was there two weeks ago.
I'll assume you're using Python2. I believe Distribute and Pip are recommended for Python3 (which I will be using as examples). I will also assume you are on Windows.
First, python needs to be registered to Path. To check if this has been done automatically, open a command prompt (start -> programs -> accessories), and type 'python', then enter. If it returns the version number, etc, skip down a bit. If it throws an error, you need to add Python to Path.
Adding Python to Path
To add Python to Path on a Windows computer, go to:
Control Panel -> System -> Advanced Settings -> Environment Settings -> System Variables
Scroll down to select path, then click edit. Copy the entire line to a text document, and add your install directory for Python.exe (and the scripts folder) using ';' as a delimiter between different directories. Copy this back to Path and save. (Additionally close your command prompt window to reset it.)
For my Windows 7 machine, I added:
;C:\Python33;C:\Python33\scripts;
Take care when editing this file. There are many videos out there describing this in detail if you feel unsure about changing this.
Installing Modules (Such as setup_tools)
Once Python is registered in the Path file, download and unzip setup_tools to a folder within your Python install directory called 'modules'. I use ExtractNow to unzip, as it will unzip twice (as required) automatically.
Open a command prompt window again, and direct it to change directories by typing
cd [directory for module you want to install]
On my computer, this would be
cd C:\Python33\modules\distribute-0.6.40
Again, I use distribute, rather than setup_tools as it sounds like you need would for Python2. Simply use the appropriate directory. Press enter to change the directory.
Once you've entered this and it shows a changed directory, type:
python setup.py install
This indicates that you want to use the program python to use the setup.py file in the specified folder to install the module. This should be successful, and will write many lines of code.
If you want to install other modules, you would install them in a similar way. Python would automatically use setup_tools on your computer to finish each install.
Remember to import at the start of your script when using them to code:
import [module]
Happy Programming!
I have a set of functions saved in a clojure file.
How do I Provide selected set of functions and then import these functions in my other file?
You have a few options.
If it’s just a file (not in a package) then in your files, you can just use load. If your file was named “fun.clj”, you would just use the name of the file without the extension:
(load "fun")
(provided fun.clj was on your classpath). Or
(load "files/fun")
if it wasn’t on your classpath but in the files directory.
Or you could use load-file and pass it the location of your file:
(load-file "./files/fun.clj")
If you wanted to namespace them (put them in a package), then you’d put the ns macro at the beginning of your file, again put it on your classpath. Then you could load it via use or require.
Here are the docs for the functions I’ve described:
load
load-file
ns
use
require
Besides "load"ing source files, you can also use the leiningen "checkout dependencies" feature. If you have two leiningen projects, say, project A requires B (provider). In the root directory of project A, create a directory called "checkouts". Inside "/checkouts" make a symbolic link to the root directory of project B.
- project A
- project.clj
- checkouts
- symlink to project B
- src
- test
in project A's project.clj, declare project B as a dependency in the :dependencies section as if it were a project in clojars.org. E.g.
(defproject project-a
:dependencies [[org.clojure/clojure "1.5.1"]
[project-b "0.1.0"]])
The thing though is, you have to go into project B and type:
lein install
That will compile project B's files into a jar file, which will appear in your ~/.m2 directory, which is kind of like your local clojars.org cache.
Once you set all this up, in your *.clj src file(s) of project A, you can "require" project B files in the normal way, as if it were from clojars.org:
(ns project-a.core
(:require [project-b.core :as pb])
This way, you can refer to functions in your project-b.core the usual way like this:
pb/myfunction1
In my opinion, this is a pretty good way to share libraries and data between Leiningen projects while trying keep each Leiningen project as independent, self-contained, and minimal as possible.
This one solved my problem and I have looked through countless other issues here so I would like to clarify.
The easiest way in emacs (on linux) is to do something like this:
java -cp "lib/*":. clojure.main -e "(do (require 'swank.swank) (swank.swank/start-repl))"
(note the "lib/*":. given to -cp
Then you can use M-x slime-connect to connect with this instance.
Don't know if it's required, but I have read that it's a good idea to use the same version of clojure, clojure-contrib and swank-clojure on both sides.
You can also setup the path inside emacs by consing the "." to swank-clojure-classpath.