I have a git repository for a project with a .teamcity folder in it containing versioned teamcity settings. Assuming I have deleted this project from the teamcity server (by first disabling versioned settings and then deleting the project) how can I re-import it?
The use case here is being able to create a new project using a template generator, e.g. yeoman or dotnet new, and be able to import that easily into a parent TeamCity project.
Our current teamcity version is: TeamCity Enterprise 10.0.4 (build 42538), so things may have improved in later versions.
So I think I have figured this out, these are the steps that worked for me.
Create a new project, making sure the Project ID is set correctly
Add a VCS root pointing to your repo that contains your project
Enable versioned settings making sure to select use settings from VCS and choosing the Kotlin settings format
Select "Import settings from VCS" when prompted
In more detail...
Make sure the Project ID for your project matches what you have in your .teamcity file
For example if your .teamcity file contains .teamcity\MyAwesomeProject, then you need to make sure your Project ID in teamcity is set to MyAwesomeProject.
use settings from VCS
If you don't tell TeamCity to use the vcs settings by default then it will do what it usually does and start checking things into source control for you.
Related
Every time I clone a repo I have to manually set the maven home directory under File->Settings->Build, Execution, Deployment->Build Tools-> Maven-> Maven home directory which is very annoying. I searched jetbrains forums and there is only an option to configure the IDE for FUTURE projects which under circumstances can never be a fact. Cloning a repo into idea projects is not creating a new project and therefore the global settings do not get triggered. How can I do this? Btw it not only applies to Maven home dir but also Code Style settings and many other more - see here
IntelliJ IDEA doesn't have a feature to propagate any setting to all the existing projects. A request is welcome.
I have question about correct configuration of VCS in TeamCity for projects.
I have a lot of small projects in one repository on GIT. It implies a lot of projects for one template in TC.
Because of that TC works very slow. For example 300 projects could compile all day.
I found the reason, in version control settings, when I want to download only one project from git I have to set checkout rules and define path to it.
This cause clearing and downloading new source codes for every compilation on TC.
When I clear checkout rules and TC agent download all repository it work fast and download only changes from git, not re-download all files of project like before. After this change projects compile 2h.
Problem with that configuration is showing changes in TC project for whole repository, when someone add new commit it appear to every project and is in history.
Do anyone know how to configure TC for working correct in that situation?
Additionally configuration issue which is necessary for every project is VCS for downloading external codes repository and common codes from the same repository where is project but different path.
For example:
C:\Projects\3rdPartySources\ - [for every project, different repository]
C:\Projects\src\ProjectA\ - [same repository]
C:\Projects\src\ProjectB\ - [same repository]
C:\Projects\src\ProjectC\ - [same repository]
Inside the VCS Checkout rules, you can specify specific rules like this:
+:Common
+:ProjectA
Or, you even can specify a custom variable :
+:Common
+:%PathToBuild%
Then, you will just have to set this var inside the "parameters" tab on each build configuration.
And, you will use the same checkout rules everywhere in your configuration.
I am working on Team-city 9.x. I have some build failures in one of the release project. although we have disabled the build and we do not want to run the build.
I am trying to move the build to another project (Disabled builds) but I cannot move the build.
Since I am getting an error as below
So I created the same VCS roots same as the release project for disabled-build project but still I am getting the same error.
It sounds like the VCS root hasn't been created at a level that can be shared by both projects from it's current location.
If you move the original VCS root to a level that is above both the current project and the one you're moving it too, it can be shared by both and you'll be able to move the project.
I would move this to <Root project> initially to help you move the project and then determine the best location for it depending on where it's being used in other build configurations
Hope this helps
I have been working on organizing legacy code. The svn version of the project was so messed up and 2/3 of the directories in svn have never been used. SO many test-folders...
So I decided to create a new project in IntelliJ and check out only those directories that we use.
This took some time as I was learning about Maven and IntelliJ. In the meantime one of my colleagues have been adding changes to the existing svn project.
So, I was wondering how can I add his changes to my local working copy before I check in my project as a new project in subversion?
I know I can look into the history and add changes manually but is there another way?
I am new to Jenkins CI tool and I want to know if it is possible to specify what build to use when there are several projects, on different SVN locations, dependent on one another. For example, if I have the web project on SVN location1 and the backend project on SVN location2 and the web depends on the backend and one of the developers modifies something in backend, when the web developer does a commit, there will be a build failure. Is there the possibility to specify that the build from the web part should take into consideration build x from backend and not the newest build?
Thanks in advance.
yes that can be done. in Jenkins check for the Build Triggers options in your project web-settings and on the line Build after other projects are built you can specify the name of projects you want to build automatically after there has been changes made to the base project.
And similarly, in the Post-build Actions, look for Build other projects, where you can specify that if the base project builds successfully, it will automatically trigger a build on children projects.
Hope this helps.
Your example of building a project against a specific version of another project is a little non-standard, but not impossible.
In your case, I would use Jenkins' ability to execute arbitrary scripts to help. The script would take care of getting the correct version of the project that the one I want to build depends on.
Building on your example of a Web and Backend project, here's how I would do things without using a parametrized build:
Add a file to the repository of the Web project that stores the version of the Backend project to use
Configure a job to build the Web project when the source for the backend project changes in SVN.
The project should check out the latest version of the Web project
The first Build Step for the project would be a script (Execute Shell or Execute Windows Batch Command) that does the following:
Gets the version of the Backend to use from the file containing the version info
Either pulls the appropriate version of the Backend from the Backend's repository; or pulls the source of the appropriate version of the Backend's source
(If you pulled the source only for the Backend, the next Build Step should be to build the Backend next)
Build the Web piece
Do any unit tests