How do I back up the build process (e.g. run this PowerShell script, run the build whenever a commit to VCS happens, not the build data) in TeamCity?
As an Adimistrator, log in, go the Administration page and look down the left side. Under Server Administration, toward the bottom of the list, is Backup. What is backed up varies by version. On mine (v8.1.1) the "Basic" setting says that the backup scope is (emphasis mine):
database
server settings, projects and builds configurations, plugins
supplementary data (settings history, triggers states, plugins data, etc.)
Related
TeamCity automatically stores files it believes are build artifacts. All of our artifacts are stored in Octopus Deploy, so this is unnecessary.
How do you configure TeamCity not to store build artifacts?
If you do not want to save artifacts, just remove Artifact paths from all projects
One more suggestion. Open Global Settings, sets Maximum build artifact file size to 0 Kb
Also, you can clean all the collected data
go to Administration > Server Administration > Clean-up Settings
The Previous clean-up section of the server clean-up settings enables you to:
review the information on the previous server clean-up date and duration helping you decide whether to launch the clean-up process at a given moment
run clean-up manually using the Start clean-up now button
During clean-up, TeamCity reports the progress. If you need, you can stop the clean-up process and the remaining data will be removed during the next clean-up.
Just press the button Start clean-up now
TeamCity doesn't store build artifacts by default.
Confirmed by Julia Reshetnikova in a support ticket:
What's happening is that a build step is pushing the artifacts using service messages. Configure the build steps to not push artifacts.
If the build steps do not allow configuring this, then the best thing you can do is configure a clean-up rule to remove build artifacts as fast as possible.
Go to the settings
Click on Clean-up Rules in the left navigation.
You may see multiple "build configuration or template", for each:
Click Edit.
Under "Clean Artifacts", choose custom policy.
Choose 1 days since last build or "1th" successful build, whichever makes the most sense to you.
All subprojects under will inherit this configuration. After this is configured, you can force TeamCity to run a cleanup by:
Go to the Administration page
Choose Clean-up Settings in the left navigation
Click "Start clean-up now"
I'm migrating continuous integration system from Teamcity to Jenkins. We have a single svn repository for all our projects like this:
project/dev_db_build (folder)
project/module1 (folder)
project/module2 (folder)
projets/pom.xml
For building db on CI server I use url project/dev_db_build and can pol this url to trigger builds when there are changes.
For building application I use url project/ So if I poll it and there are changes to dev_db_build application build should be ignored and triggered after db_build as successful.
In teamcty I used "Trigger patterns" for this. But in Jenkins there are so many triggering plugins https://wiki.jenkins-ci.org/display/JENKINS/Plugins#Plugins-Buildtriggers - I looked into some of them and have not found suitable.
Ideally, you should use a post-commit hook as suggested by #Mike, rather than polling. Otherwise, when configuring the Jenkins job, under 'Source Code Management' with 'Subversion' selected, there is an advanced button. Clicking this reveals an number of options, including 'Excluded Regions'
If set, and Jenkins is set to poll for changes, Jenkins will ignore
any files and/or folders in this list when determining if a build
needs to be triggered. Each exclusion uses regular expression pattern
matching, and must be separated by a new line.
/trunk/myapp/src/main/web/.*.html
/trunk/myapp/src/main/web/.*.jpeg
/trunk/myapp/src/main/web/.*.gif
The example above illustrates that if only html/jpeg/gif files have
been committed to the SCM a build will not occur. More information on
regular expressions can be found here.
In your case, you would set 'Excluded Regions' to something like
/project/dev_db_build/.*
Do you have the ability to edit your Subversion hooks? Instead of having your Jenkins server poll SVN, I would recommend that you have SVN call Jenkins via a post-commit hook to automatically kick off a build upon developer commit. This has the effect of lessening the load on both the Jenkins and SVN servers as well as not having a waiting period of however long your polling interval is before a build is kicked off.
In my CruiseControl instances, I have version controlled the ccnet.config file.
When I want to update CruiseControl, I run an "update config" job which fetches the config from version control.
In this manner, the very build process of a release is configuration managed.
I am wondering how to achieve these goals effectively under TeamCity.
I try to keep what ever CI I am using as light as possible and put as much of the running of the build into an msbuild or nant script including running tests, code coverage, etc.
The benefit of this is:
The build file is version controlled.
You can run the script in any environment.
Easier to move between CI environments.
Everyone becomes responsible for the build.
This has been introduced in TeamCity 9. Also answered in another post:
Version control (e.g. in TFS) build configuration for TeamCity - is it possible?
I've been wanting a way to source control TeamCity config for a long time. I ended up writing a Windows Service which monitors the configuration directory and commits changes to git.
The project is on GitHub: https://github.com/grenade/teamcity-config-monitor
You might try looking at the folders that are backed up prior to upgrade (or when restoring team city) as those represent the configurations and changes you've made since initial installation.
http://confluence.jetbrains.net/display/TCD4/TeamCity+Data+Backup
Some of the relevant data is actually a database, (and in fact the documentation advises you to point team city to a real database like mysql instead of the default embedded database it uses)
You could try checking those into SVN, but you'll want to stop team city for any check-in actions.
We have a continuous integration server with over 40 jobs that are constantly changing. I would like to version control continuous integration build jobs in Hudson so we can roll back changes if we have problems.
Is there a Hudson plugin that will do this or other solution that already exists or should I keep the config.xml files in SVN.
Hudson Labs has a really great write up on this, Keeping your configuration and data in Subversion
This is the first bit of the article
We all know that keeping important
files in version control is critical,
as it ensures problematic changes can
be reverted and can serve as a backup
mechanism as well. Code and resources
are often kept in version control, but
it can be easy to forget your
continuous integration (CI) server
itself! If a disk were to die or fall
victim to a misplaced rm -rf, you
could lose all the history and
configuration associated with the jobs
your CI server manages.
It’s pretty simple to create a
repository, but it isn’t obvious which
parts of your $HUDSON_HOME you’ll want
to backup. You’ll also want to have
some automation so new projects get
added to the repository, and deleted
ones get removed. Luckily we have a
great tool to handle this: Hudson!
We have a Hudson job which runs
nightly, performs the appropriate SVN
commands, and checks in
You only seem to be interested in the configuration, which is fine, just ignore or filter out the bits about the data and focus on the configuration.
This is one of the more recent threads about using version control with Hudson's configuration on the Hudson users list.
There are no plugins to do store configuration in an SCM right now (March 2010) though the backup plugin might do something close to what you want, but perhaps with less of a view of 'change' and more of just a snapshot at any given time.
The relatively new Job Config History plugin gets part of the way there - it doesn't actually store the configurations in source control, but it does provide history and auditing of changes to jobs.
You could look into the SCM Sync configuration plugin.
It automatically commits all of your jenkins config changes to svn. that way you can track configuration errors easily.
https://wiki.jenkins-ci.org/display/JENKINS/SCM+Sync+configuration+plugin
Is there a way to configure Hudson to only execute Build or Post Build actions if there are changes in SVN/CVS
Thank you
You can have Hudson poll the SCM for changes and only do things if it finds changes.
Poll SCM: Configure Hudson to poll changes in
SCM.
Note that this is going to be an
expensive operation for CVS, as every
polling requires Hudson to scan the
entire workspace and verify it with
the server. Consider setting up a
"push" trigger to avoid this overhead,
as described in this document
You can also add something to your SCM post-commit hooks that will fire off a Hudson build.
Trigger builds remotely (e.g., from
scripts):
Enable this option if you would like
to trigger new builds by accessing a
special predefined URL (convenient for
scripts).
One typical example for this feature
would be to trigger new build from the
source control system's hook script,
when somebody has just committed a
change into the repository, or from a
script that parses your source control
email notifications.
You'll need to provide an
authorization token in the form of a
string so that only those who know it
would be able to remotely trigger this
project's builds.
It is not as simple as looking at the revision number (as stated elsewhere) unless your build is for the entire subversion repository. Typically you have projects sharing a single subversion repository and you are building some sub-tree. The global revision number doesn't help.
'svn info [url_to_subtree]' will show the Last Changed Date. You can parse this and figure out if it is later than your last build date and trigger a new build.