I accidentally deleted some builds for a job that I would have rather kept. I restored the builds on disk from backup, but they still do not show up when I am on the status page for that job.
I have tried both triggering another build for the job and re-starting Hudson.
How can I fully-restore these builds? Is there a DB that Hudson uses to store this type of information?
Inside your %HUDSON_HOME% directory is a subdirectory called "jobs". Under "jobs" are subdirectories for every project. Inside each one are subdirectories for each build.
You need to make sure that jobs\<projectname> exists, and then copy the missing build directories inside.
Click "Manage Hudson/Reload Configuration From Disk" to make Hudson recognize the newly added builds. Not necessary to restart your servlet container (e.g. Tomcat) if you use one.
Depends what you restored. It sounds like you restored the workspace folder, but this folder is irrelevant for historical information. I would first shut down Hudson and than restore the build folder and the modules folder. Than you can restart Hudson. For more information ask the Hudson project.
In addition to Williams (https://stackoverflow.com/a/3399103/142207) answer you'll need to re-add it to all the custom views.
Related
Our Team City server got to a state when nothing works including the `Start clean-up now' button, because the internal database size is >900MB. Yes, we are still trying to get a proper external database... In the meantime is there a way to shut down Team City and run the clean-up manually from the command line? How can we recover from this state otherwise?
We are running version 8.1.5.
It depends a lot on what do you want to clean up : artefacts, directory etc.
I ran into the same issues when I setup teamcity initially. I used to go into the agent work directories , figure out the directories taking the max space and run rm -rf on the agent work directories (the ones with the alphanumeric sha id) .
One good thing about our setup is that we named all our checkout directories , so it was very easy to identify multiple runs for the same build, so I used to delete every checkout build except the latest one.
In case you have artefact dependencies, I would advise you not to do this process
I want to attach some file as option in TeamCity 8.1 Build Run dialog form.
Before start build this file must be copied into defined place on the Agent side.
Who knows, is it possible? I can't find any plugins for it.
Tnx.
Where does this file normally reside? ie: where would TeamCity get it from?
Where should this file be copied to on the build agent? Can it be placed in the sandbox (work folder) for a given project?
If the file is stored in source control, you can specify a VCS root to get it copied over to the sandbox the same way you specify a VCS root to get the source code you wish to build copied to the sandbox.
For our projects, we regularly specify two VCS roots for a single project: one to copy some scripts and utilities our build requires and one to copy the actual source code that needs to be built.
Hope that helps!
I am currently working on a project which is included in a versions(svn)repository. Although I'm not sure, I think I might have changed some settings in Xcode, affecting the way the source control saves the build folder in the repository. I was told it is a bad practice to commit the build folder, and asked why have I done that, but I had no answer at the moment. A screen will elucidate this more clear:
Even if I tried to delete (or ignore) those files from the repository, they are still created after I build the project. How should I proceed in order to prevent those build folders appear in versions' project tree?
Adding versioned folder to ignore-pattern does not affect data in SVN
You must ignore and remove folder from SVN, but keep it locally
For CLI it will be svn pe ... in the parent of build folder and svn rm build --keep-local (I don't know XCode GUI's equivalents)
I have a scenario like that described here.
Unfortunately, the solution doesn't work for me. My build project has a folder named bin where all external DLLs are stored and referenced. The problem I'm having is this: the bin folder is created under the working folder when queueing a build, but it's empty and consequently the build fails.
Any idea why this would happen and how to go about fixing it?
EDIT - Everything is checked into TFS and the build definition workspace is set to two levels above the bin folder. The working folder above refers to the build agent working folder (as opposed to the build definition workspace).
I'm not sure what the linked question has to do with your bin folder problem description.
But if you have stored binary dependencies in your bin folder (bad practice), you just need to make sure that they are checked into TFS, and the build definition workspace mapping includes that bin folder (or one of it's higher level ancestors), and the Get that happens at the start of the build process should download whatever is in TFS to the build agent.
It's important to note that the TFS Build by default doesn't output into the bin/debug folder, but that shouldn't matter for picking up references.
I'm having an issue with TeamCity, which relates to the fact that it runs the source control step before it runs the build steps. My project is a windows service, so there are complications with this.
TeamCity often decides to delete the entire contents of the project directory, even though I have the clean build option unchecked. However, since this is a windows service this does not fly, as when trying to delete the dll's it errors out since they're in use:
Error while applying patch: Failed to delete: F:\PathToService\bin\Release\Library.dll
The most frustrating part is that the dll's aren't even under source control, TeamCity seems to have a mind of its own and decides to delete them anyway.
Is there a way to get around this, to be able to run a build step BEFORE doing the svn checkout so that I can stop the windows service first?
I would try to set up your CI environment so it uninstalls the windows service once you are done testing it. I am not aware of Teamcity pre-checkout hook.
The answer was to split up each service into a separate working directory. That prevents teamcity from deleting the dll's.