jenkins continuous delivery with shared workspace

Question

Background:

We have one Jenkins job (Production) to build a deliverable every night. We have another job (ProductionPush) that pushes out

Answer 1

Answer 2: Yes, sharing workspace is a bad idea. There is possibility of file locks. There is the issue of workspace being wiped out. Just don't do it...

Answer 1: What you need is to Archive the artifacts of the build. This way, the artifacts for a particular build (by build number) will always be available, regardless of whether another build is running or not, or what state the workspaces are in

To Archive the artifacts

• In your build job, under Post-build Actions, select Archive the artifacts
• Specify what artifacts to archive (you can use a combination of below)
  a) You can archive all: *.*
  b) You can archive a particular file with wildcards: /path/to/file_version*.zip
  c) You can ignore the intermediate directories like: **/file_version*.zip
• To avoid storage problems with many artifacts, on the top of configuration you can select Discard Old Builds, Click Advanced button, and play around with Days to keep artifacts and Max # of builds to keep with artifacts. Note that these two settings do not control for how long the actual builds are kept (other settings control that)

To access artifacts from Jenkins

• In the build history, select any previous build you want.
• In addition to SCM changes and revisions data, you will now have a Build Artifacts link, under which you will find all the artifacts for that particular build.
• You can also access them with Jenkins' permalinks, for example
  http://JENKINS_URL/job/JOB_NAME/lastSuccessfulBuild/artifact/ and then the name of the artifact.

To access artifacts from another job

I've extensively explained how to access previous artifacts from another deploy job (in your example, ProductionPush) over here:
How to promote a specific build number from another job in Jenkins?

If your requirements are to always deploy latest build to Production, you can skip the configuration of promotion in the above link. Just follow the steps for configuration of the deploy job. Once you have your deploy job, if it is always run at the same time, just configure its Build periodically parameters. Alternatively, you can have yet another job that will trigger the deploy job based on whatever conditions you want.

In either case above, if your Default Selector is set to Latest successful build (as explained in the link above), the latest build will be pushed to Production