Some of that is not quite correct. A 'build' is a specific run of a job, yes, and Jenkins stores the logs, parameters and other metadata associated with the build, along with any data produced by publishers used in the build (unit test reports, warnings analysis, stuff like that). It does *not* copy any content from the workspace into the build, and it doesn't keep any content from the workspace by default. You can confirm this by running a job build on a slave and then taking the slave offline; if you then go look at that build in the history you'll see that the Workspace is gone (or empty), and if you bring the slave back online and run a different job the Workspace link from the first job will show you the current contents of the workspace (which is not especially useful).
If you need to preserve files produced by the build steps themselves, those are artifacts, and you'll need to enable artifact preservation to get Jenkins to copy and store them. ----- Original Message ----- From: jenkinsci-users@googlegroups.com To: jenkinsci-users@googlegroups.com At: Jan 25 2013 06:32:18 Hi Paulo, It's tricky when you start, I remember finding this all a bit confusing too! On 25/01/2013 11:16, Paulo Matos wrote: > * Builds are the files created during a job. My understanding is that a build is a specific, numbered run of a job. > So if a job triggers the > creation of 2 files and 3 directories, that's the build and it exists in > the workspace. Well, the build is a number. Each build uses a workspace, and the job may create files in that workspace. Jenkins keeps a copy of the workspace for each build, unless you configure it not to... > Artifacts are files/directories that are stored by > jenkins outside the workspace and can be copied between jobs. Indeed, although they're still tied to a build. An artifact might be "'mydist.tgz' from build number 10 of the 'make_things' job". > Now, if this is correct, how does it work when we say: 'keep a maximum > amount of 5 builds'? That means "keep up to 5 copies of the workspace, one for each build". > Does jenkins take a snapshot of workspace before a > job is run I think it's after... > and knows what was created during the job execution and makes > that the build? I believe it's just a copy of the workspace as it was, so no knowledge is used... > * If I have a job and create a tarball in a script to use as artifact, > the tarball is created in workspace and then the artifact [tarball] is > copied automatically by jenkins somewhere else. If you configure the saving of artifacts as a post action. > However the tarball > stays in workspace occupying precious space. How can I instruct jenkins > that all that is made into an artifact should be removed from workspace? I think this might be what you're after: https://wiki.jenkins-ci.org/display/JENKINS/Workspace+Cleanup+Plugin > * When I run a downstream job and copy artifacts from upstream into > workspace/artifacts, is there a way to remove all the artifacts from > previous build or this needs to be done manually through a script? You can also configure how long to keep artifacts in old builds... cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk --
