Is it possible in a Hudson job to specify a different Source directory to poll to the directory in which a build is run ?
I've used Hudson successfully to enforce compilation success in java projects.
An SVN directory is polled every say 5 mins and an ant target specified - the errant programmer getting emailed in the event of failures.
However in every case the ant build.xml happened to reside in the same directory as the SVN directory being polled.
Basically I am trying to apply the same system to an Oracle database build.
There are multiple directories to watch (schema, static data, stored procs etc and an upstream / downstream order).
However the ant build script resides several directories above the directories I wish to poll.
I guess the solution is I must create multiple ant build.xmls one for each database component and I assume a separate Hudson job for each ?
I wondered was there a better way of doing this.
Best Rgds
Peter
Checkout the project from the highest level and configure your build steps to execute the various steps in the the sub folder as you would do it manually. As long as everything needed is in the workspace you can build whatever is in there in the top level as well as sub folders.
Related
We are using GitHub Action Self Hosted Runners on a Windows Server to build and deploy private repositories. For context, they are .NET Projects.
A pattern we've adopted is to break out a workflow into multiple jobs (checkout, restore, build, test & deploy). Some of these jobs can be run in parallel, some need other jobs to complete before they can start.
I have tried to set up two Runners in the same Runner Group on the same machine.
My Expectations:
Be able to run multiple workflows at the same time (one runner per workflow)
Be able to run multiple jobs in a single workflow at the same time (multiple runners per workflow)
Self Hosted Runners have their own folder: _work which is where $Env:GITHUB_WORKSPACE points.
When I tried #2 above, I saw both runners working on the same workflow, but they were using their own respective _work folders. The first runner would check out a repo to its _work folder and the second runner would error out because it couldn't find the repo in its _work folder.
Possible Solutions:
A) Move the _work directory to a root folder that both runners can access
B) Remap $Env:GITHUB_WORKSPACE for each workflow
I don't believe either of these solutions works, what am I missing? Is there a better technique here for using multiple self hosted runners?
I would even be happy if I could have my #1 expectation of one runner per workflow.
So, I'm enjoying using composer, but I'm struggling to understand how others use it in relation to a deployment service. Currently I'm using deployhq, and yes, I can set it to deploy and run composer when there is an update to the repo, but this doesn't make sense to me now.
My main composer repo, containing just the json file of all of the packages I want to include in my build, only gets updated when I add a new package to the list.
When I update my theme, or custom extension (which is referenced in the json file), there is no "hook" to update my deployment service. So I have to log in to my server and manually run composer (which takes the site down until it's finished).
So how do others manage this? Should I only run composer locally and include the vendor folder in my repo?
Any answers would be greatly appreciated.
James
There will always be arguments as to the best way to do things such as this and there are different answers and different options - the trick is to find the one that works best for you.
Firstly
I would first take a step back and look at how you are managing your composer.json
I would recommend that all of your packages in composer.json be locked down to the exact version number of the item in Packagist. If you are using github repo's for any of the packages (or they are set to dev-master) then I would ensure that these packages are locked to a specific commit hash! It sounds like you are basically there with this as you say nothing updates out of the packages when you run it.
Why?
This is to ensure that when you run composer update on the server, these packages are taken from the cache if they exist and to ensure that you dont accidentally deploy untested code if one of the modules happens to get updated between you testing and your deployment.
Actual deployments
Possible Method 1
My opinion is slightly controversial in that when it comes to Composer for many of my projects that don't go through a CI system, I will commit the entire vendor directory to version control. This is quite simply to ensure that I have a completely deployable branch at any stage, it also makes deployments incredibly quick and easy (git pull).
There will already be people saying that this is unnecessary and that locking down the version numbers will be enough to ensure any remote system failures will be handled, it clogs up the VCS tree etc etc - I won't go into these now, there are arguments for and against (a lot of it opinion based), but as you mentioned it in your question I thought I would let you know that it has served me well on a lot of projects in the past and it is a viable option.
Possible Method 2
By using symlinks on your server to your document root you can ensure that the build completes before you switch over the symlink to the new directory once you have confirmed the build completed.
This is the least resistance path towards a safe deployment for a basic code set using composer update on the server. I actually use this method in conjunction with most of my deployments (including the ones above and below).
Possible Method 3
Composer can use "artifacts" rather than a remote server, this will mean that you will basically be creating a "repository folder" of your vendor files, this is an alternative to adding the entire vendor folder into your VCS - but it also protects you against Github / Packagist outages / files being removed and various other potential issues. The files are retrieved from the artifacts folder and installed directly from the zip file rather than being retrieved from a server - this folder can be stored remotely - think of it as a poor mans private packagist (another option btw).
IMO - The best method overall
Set up a CI system (like Jenkins), create some tests for your application and have them respond to push webhooks on your VCS so it builds each time something is pushed. In this build you will set up the system to:
run tests on your application (If they exist)
run composer update
generate an artifact of these files (if the above items succeed)
Jenkins can also do an actual deployment for you if you wish (and the build process doesn't fail), it can:
push the artifact to the server via SSH
deploy the artifact using a script
But if you already have a deployment system in place, having a tested artifact to be deployed will probably be one of its deployment scenarios.
Hope this helps :)
I currently have Jenkins set up with a number of jobs, but it's proving difficult to back up because the artifacts are stored within the job directory. I'd like to back up the job configurations and artifacts separately. I'm sure I remember reading somewhere that Jenkins now has an option to store them outside the job, but I can't find this.
Is there any configuration option that does this while still making the artifacts visible from within the job on the Jenkins interface? (ie rather than merely an add-in that copies the artifacts elsewhere)
Go to your jenkins configuration page, e.g.
http://mybuildserver.acme.com/configure
At the top of the configuration page there is a "home directory" setting. Click the "advanced..." button below it.
Now set the "Workspace Root Directory" to e:\jenkins-workspaces\${ITEM_FULL_NAME}, and "Build Record Root Directory" to e:\jenkins-builds\${ITEM_FULL_NAME} or something similar.
Warning: I run Jenkins 2.7.2 and noticed that certain features don't work properly after configuring Jenkins like that. I saw problems with folders and problems with the multi-branch project plugin. Check the status of those issues if your rely on these features.
As you can see here, there are many plugins to deploy artifacts anywhere you want/need, on FTP, CIFS, Confluence, Artifactory.... especially the ArtifactsDeployer that will allow you to make a copy of the artifacts in the Jenkins Home.
Thank you Sam, for your post, which directed me into the right direction to solve my problem.
Have been searching for a way on how can I make a symlink to the Job-Archive of a build for multibranch projects. Up to now, we used to manually search for the correct folder basename in the filesystem and added that one to the Jenkinsfile.
Now, I can simply use
jobOutputFolder = currentBuild.rawBuild.artifactsDir.path
and use that in my script.
If security is a concern, I could implement that as a shared library additionally.
Try the Use Custom Workspace build option. From the Jenkins popup help:
For each job on Jenkins, Jenkins allocates a unique "workspace
directory." This is the directory where the code is checked out and
builds happen. Normally you should let Jenkins allocate and clean up
workspace directories, but in several situations this is problematic,
and in such case, this option lets you specify the workspace location
manually.
This option is also available under advanced project properties of multi-configuration project builds.
A groovy script under "Prepare an environment for the run" will always run on the master, and this groovy script can create a symlink to where you really want artifacts archiving to archive_to which SHOULD include the job name and build number:
if (! Files.createSymbolicLink(Paths.get(currentBuild.artifactsDir.path),
Paths.get(archive_to.getCanonicalPath()))) {
throw new RuntimeException("Can't create symlink to archive dir")
}
Of course (sadly) when old builds are purged by Jenkins the old artifacts are left because jenkins will not follow a symlink when purging, even if jenkins owns the symlink and the target (shame).
I workaround for that may be to point a symlink back from the new archive dir, then, when jenkins purges it's archive dir, the new symlink will dangle and a cron job can then later delete the new job archive dir
Copy Artifact Plugin (https://wiki.jenkins-ci.org/display/JENKINS/Copy+Artifact+Plugin) adds a build step for retrieving files from another project's workspace to current and work from there.
Is there any way to have the war files of Hudson in an different directory or drive that the job files.
We want to have all executables in c:\programme\hudson and all jobs in f:\data\hudson.
I've alredy played around with in hudson.xml. But this redirects not only the job directory but copies also the whole war directory to the new destination folder.
Is there any way to configure Hudson (on a windows server) to have a separation of the executable and the data/job directories?
Seting HUDSON_HOME to f:\data\hudson should do the trick
I think this problem has not an easy solution. Besides deploying to an app server, I can come up with two options.
Configure the workspace explicitly in every job to point to F:\data\hudson
create a file system link from c:\programme\hudson\jobs to f:\data\hudson. I have never used it. So have fun reading through the following links. hard links and junctions, symbolic links
I'm not sure if this is what you want, but I run hudson simply via java -jar, and then I can specify freely where the hudson war is. It seems the war unpacks into HUDSON_HOME when starting up, but I still have a separate directory where I keep the wars and download upgrades, and I can just change the shortcut when I want to run a newer war.
We run Hudson on a Windows server and use Tomcat as our container.
In this setup, you can set HUDSON_HOME to whatever you want, which holds the job configuration, and then the HUDSON.WAR file lives in C:\Program Files\Apache Software Foundation\Tomcat 6.0\webapps.
Question:
In the path HUDSON_HOME/jobs/<jobname>/builds/<timestamp>/workspace-files, there are a series of .tmp files. What are these files, and what feature of Hudson do they support?
Background
Using Hudson version 1.341, we have a continuous build task that runs on a slave instance. After the build is otherwise complete, including archiving the artifacts, task scanner, etc., the job appears to hang for a long period of time. In monitoring the master node, I noted that many .tmp files were being created and modified under builds//workspace=files, and that some of them were very large. This appears to be causing the delay, as the job completed at the same time that files in this path stopped changing.
Some key configuration points of the job:
It is tied to a specific slave node
It builds in a 'custom workspace'
It runs the Task Scanner plugin on a portion of the workspace to find "todo" items
It triggers a downstream job that builds in the same custom workspace on the same slave node
In this particular instance, the .tmp files were being created by the Task Scanner plugin. When tasks are found, the files in which they are found are copied back to the master node. This allows the master node to serve those files in the browser interface for Tasks.
Per this answer, it is likely that this same thing occurs with other plug-ins, too.
Plug-ins known to exhibit this behavior (feel free to add to this list)
Task Scanner
Warnings
FindBugs
There's an explanation on the hudson users mailing list:
...it looks like the warnings plugin copies any files that have compiler warnings from the workspace (possibly on a slave) into a "workspace-files" directory within HUDSON_HOME/jobs//builds/
The files then, I surmise, get processed resulting in a "compiler-warnings.xml" file within the HUDSON_HOME/jobs//builds/
I am using the "warnings" plugin, and I suspect it's related to that.