Does anyone know how I can configure bamboo to purge it's old builds. I have clover running and my server has just run out of space. I have discovered that for each build the clover directory is about 100 MB. It's full of all the code coverage reports. It would be good to have perhaps the last 10 clover reports but I don't need all of them. Can I get Bamboo to purge it's old builds?
As it is not purging the bamboo-data directory gets bigger and bigger and bigger each time it builds. (which happens many times a day)
On my machine this directory contains loads of build files.
/usr/local/bamboo-data/artifacts/PROJECT_NAME/JOB1/build....
I could just create a script that runs under cron to do the delete but it seems like this should be common problem so I'd like an Atlassian base solution.
I think I have figured this out. In the build configuration there is a Build Expiry option. According to the Atlassian docs I can enable this to delete old artifacts and test result. I have set it in my build and will see what happens when it is time to run.
Related
We have CI set up on a solution within the company.
The build was taking roughly 13 minutes in total, which seemed a bit a too long. After some digging around, I found out that the we were not passing the /maxcpucount switch to the msbuild command, and so each project was being built in sequence as opposed to parallel. Adding this switch dropped our build time down to 3 minutes.
However, we started seeing builds intermittently failing with the message that a cached nuget package was already being used by another process. The project that would fail to build, and the locked nuget package would change every time.
This turned out to be because we were building multiple projects within the same solution at the same time, and we could get the circumstance whereby two projects building in parallel tried to access the same locally cached nuget package at the same time.
We surely can't be the only people with this problem, as it seems like it would be quite common. Does anyone have experience with this problem? Are we doing something wrong? How can we prevent these builds from failing?
So I finally figured what was causing this, although I can't figure out why.
In our Teamcity MSBuild step, we had our Working Directory set to %build.root%. Removing this value, so that the default of the checking directory was used, appears to have stopped that error from occurring.
I have an IntelliJ project with several modules. Some of the modules should be run as servers. For every server (module), I have a run configuration.
Can I bundle those run configurations together, so I don't need to click run or stop five times?
If it matters, the project is fully mavenized.
The previously accepted answer does not work for running multiple servers or any scripts which do not terminate. However, now you can use the Compound run configuration to execute multiple non-terminating servers simultaneously. It looks like this:
Steps to get it working:
Create the individual run configurations
Create a new compound configuration
Choose the desired individual run configurations.
Run the new Compound configuration.
Go to the intellij documentation.
All the individual configs will run simultaneously - perfect for servers and other threads which do not exit!
NOTE: Even the MultiRun plugin recommends using Compound on their GitHub page.
More info in the IDEA documentation.
Update
This now is possible (despite the fact that the issues #CrazyCoder linked to are still open as of this date). In Intellij 12, you can "Run Another Configuration" before launch when you're in "Edit Configurations". Here's a screenshot:
Check out this Multirun plugin.
And yes, I found it following CrazyCoder's link, so props to him again!
I found that 'Compound' sorted all modules alphabetically and launched them in that order. This could be a problem if there are modules with dependencies. If there is a way to override that sorting, I could not find it.
I am using the paid version of IntelliJ 2020.2
I wanted a simple thing - Start my Spring Boot application and then start my Angular application. I tried the 'Run Another Configuration' way and it did not work. I faced the same issue as faced by #AxelFontaine.
The Multirun plugin solved my problem. I did have to restart the IDE twice - once to update it after plugin installed and the second time because there was an error saving some configuration. But since then its working just as expected. This is very helpful as I can work on the UI and see the changes immediately and similarly the Spring dev tools lets me change code and it reloads immediately. This plugin is very very helpful.
I currently have a nightly build system running as a windows scheduled task, calling at batch file, that works sort of like this:
Check out the latest revision from subversion
Modify the AssemblyInfo.vb file of the main executable and the librarys to set the version number to 0.0.0.revision
Invoke MSBuild to build everything (including the installer)
Upload the installer and a log of the build to an FTP server
This works ok, but step 2 is dirty and fragile, and I can't imagine that this the only way to do what I want. Any ideas?
There are a couple of ways to deal with this. You may want to check this post or others tagged with svn (and containing "AssemblyInfo").
I've never worked on tremendously huge projects and the workflow we use at work is check-out/code/compile locally to test/commit. I was wondering how a build server would change this process. How do developer test their code when the application is too huge to compile locally? They just code, commit and pray?
Absolutely not.
The developer usually has a build file which can build the project for him or her, which has some "targets" defined which do the testing. If you have a really big project, you may have certain portions of it precompiled for you, so you don't have to build the whole thing in one big chunk. You usually do your testing locally before you commit to your repository. Breaking the build in big projects can mark you as an object of ridicule and scorn. Breaking the build in really important, really big projects can be career limiting... ;-)
The build SERVER itself doesn't change this. The build server only runs your build file and the targets you tell it to.
There are also build components (I've just started using TeamCity - no affiliation) that allow "personal builds".
I haven't used it yet as we haven't got it set up properly but my understanding is that TeamCity allows running a build (and tests if they are any run on the server) with your changes before committing (and optionally the server will commit your changes if the build is succesful). in TeamCity this is called a Pre-Tested Commit.
Currently I'm tasked with doing the daily build. We have an ASP.NET 2005 website with a SQL Server 2005 backend. Our current source control is Visual Source Safe 2005.
At this point, I use the brute-force method of daily builds.
Get Latest version of source code
Get Latest version of Database release script
Backup old website files to a directory
Publish new code to my local machine
Run on my server to keep the test/stage site working
Push newly created files to the website
Run SQL Script on test database (assuming updates, otherwise I don't bother)
Test website on the Test Server.
Looking at the idea of automated builds intrigues me since it means that I do less each morning. How would you recommend I proceed? I want to have a fully fleshed out idea before I present it to my boss.
Ditch VSS, move to Subversion, and check out CruiseControl.NET. Alternatively, if you have a MSDN developer license, you can run TFS workgroup edition and set up a build server on any old XP box. Its what we do at our shop.
As Assaf noted, you can use CC.NET with VSS directly. Nice.
TeamCity has worked well for me. It has a very simple setup. Combine it with an MsBuild script for your operations and you're auto-matic.
For build management I wholeheartedly recommend TeamCity. It doesn't require IIS6 (like CC.net does) since it runs on it's own copy of Tomcat and the setup is all done thru various forms. This is a big deal to me since the build server is just an XPPro box. It integrates well with SVN and there is no crazy XML file manipulation like I had to do with CruiseControl.Net. Big win for me.
For a build runner we use NAnt to send emails to various people, copy the packaged builds where they're supposed to go, run NUnit and NCover, and deploy the software to our web farm.
For automated testing we use Watin.
http://www.nunit.org/index.php
http://www.jetbrains.com/teamcity
http://ncover.sourceforge.net/
http://subversion.tigris.org/
http://nant.sourceforge.net/
http://watin.sourceforge.net/
Try CruiseControl.Net. It's free, and whatever customized daily/continuous routine you want it to perform you can always add with scripts.
Remember, it's not just about daily (nightly) builds, but also about letting you catch build errors in time (since it continuously builds after every source commit/check-in). You don't necessarily test every code chance on every possible platform and build configuration, but CC can do exactly that for you (in the background).
http://confluence.public.thoughtworks.org/display/CCNET/Visual+Source+Safe+Source+Control+Block
All of what you are doing can be performed by a set of batch files, depending on how automated your test environment is. The main batch file can be started as a 'scheduled task' at midnight or whatever. That's how we 'do it cheap' here and at other places I've worked. If you need help with a particular batch, I can provide a sample.
I second (or third) the reccomendation for Subversion/CruiseControl.net. Also, if it is appropriate, check out hosted services for SVN like CVSDude. You'll probably become well versed with MSBuild in the process too. Once you get it setup it is great.
The cost doesn't come from licensing of the tools or even hardware necessarily, but from your time building and maintaining the system - and depending on what you are doing, that could become significant.
Start with the basics and incrementally improve it over time. Like anything else, if you try to come out of the gate with lots of automation and functionality you could find yourself mired in it fulltime for weeks.
Whatever tools you use, house them in a virtual machine (ie., vmware).
When the equipment inevitably goes south, you can copy the image onto any machine and not miss a beat because your build server decided to take the day off, assuming of course, you back up.