I installed CCNET to make autobuild from a GIT server.
I have a big problem here :
My Git Server Repo Structure :
Repo.git
--- Module 1(Folder 1)
--- Module 2(Folder 2)
--- Module 3(Folder 3)
--- Module 4(Folder 4)
--- Module 5(Folder 5)
--- Module 6(Folder 6)
The ccnet make trigger follow by the order Mod1 - > Mod2 - > Mod3 - > Mod4 - > Mod5 - > Mod6
but when CCNET trigger a changes anywhere(Maybe changes make in Folder 5(Module 5)), its still make a build as above order.
I dont want to do this, It will take a lot of time.
I just want to make build which module has been changed.
Somebody please help me to make ccnet do this way.
Thanks for yours reading.
In Git, if you have several directories that are always checked out independently, then these are really two different projects and should live in two different repositories. You can merge them back together at a later point using Git Submodules
An alternative approach you can use Modification Writer Task. This tasks writes to an XML file, which can be evaluated from build script or batch file. Based on this you can do your build.
the answer from #domu904 is correct.
But if you do not want to change your project structure you can try to use the Filtered Source Control.
With the Filtered Source Control you're abel to specify include and exclude filter rules for CCNet to detect modifications.
So you can include just the specific git module folder in your module ccnet project.
To trigger the dependend module ccnet projects use the Project Trigger.
Related
I am using teamcity to build my Unity3d projects. When I am selecting branch in custom build or when build is triggered from "not master branch" git performs clean, and it removes my Library folder. I need to persist this folder because it is a cache that builds a huge amount of time. When I stay on master, everything is fine and this cache is reused. How can I do this? I want this folder to be shared between my branches.
I tried to create multiple VSC roots, but it copies my repo for every branch. I also disabled all "clean" options that I found in settings. But nothing helps
You could try one of these:
In VCS Root settings you could set Clean Policy to Never. It sets whether and when TeamCity should exec git clean in working dir. Default value is "On branch change" which I guess is your case. But it means that you should manually clean your working dir from build artifacts. For more information see here
You could use Unity Accelerator
You could backup your Library folder in the end of every build and restore in the beginning of the next one
As a new Egit user, aiming to set up version control to update the way a team manages source code without changing locations of our build and dev servers and to identify correct Egit commands to use for check in and check out code from both servers.
In a single Eclipse workspace, initially had one project without use of Egit just a basic automatic and adhoc file copy back up of changed development directory into folders with dates of backup. Promotion to the build server was done by manually copying source files and binaries, doing a diff between source on the MainServer and local server to manage any merges. Now need to implement a proper version control system, using Egit, so as a first time Egit user. I have set up two test Eclipse projects in my workspace: project A shared with MainServerRepository and project B shared with LocalServerRepo. The two git repositories will be in different directories: MainServerRepository on the network and LocalServerRepo on my area on the network where I backup my PC.
What Egit actions do I take to promote latest TESTGIT1.src from MainServerRepository into LocalServerRepo to work on in my local server? (Team > Fetch from upstream is grayed out). Then, once tested, how do I check in src for TESTGIT1 into the main build server project, source and objects are in MainServerRepository?
I've used Team > Commit successfully to check in, but am using cut and paste to move code between two projects (prior to commit) and feel there must be a better way to do this or to set up the projects differently within Eclipse.
Or should I be using Team > push or Team > merge?
Do I need local repository or should I just check out into workspace?
Any comments/ question/assistance would be welcome as haven't figured it out from reading the EGit/User_Guide.
Edit TESTGIT1.src in Eclipse project shared with LocalServerRepo(testGitRepo) until work on it is complete on local server. Then, apply same changes to TESTGIT1 in the main build server project, using right click copy +paste from right click, team > check in. Then in Git Staging view, click plus sign to add to index (staging area), then click commit button, merging in with any other changes made to TESTGIT1.src by other developers. Don't use push command to push entire contents of LocalServerRepo. Or is there a better answer?
We have over 100 build configurations in Team City, and I've come to realize over the past few months that these assets are just as important (if not more so) than the actual project assets (code, config, etc) we are delivering.
To that end, I know TC provides it's own build configuration version control but to me that seems a bit low on features - for example if a build stops working it would be really good to be able to diff the actual XML build configurations in my favorite diff tool rather than rely on TC's built in one, or to be able to view differences across a longer time frame than simply against the previous state.
Obviously this can be handled manually by extracting the build definition and committing, and then applying self disciple to always do this when you change the definition. Can anyone suggest a more joined up approach? We're using TeamCity Enterprise v8.0.5
Can you upgrade to TeamCity 9? TeamCity now has built in support to sync the build configurations to Git or Mercurial.
https://www.jetbrains.com/teamcity/whatsnew/
https://www.youtube.com/watch?v=zTLeCrdxGIw
As an interim solution before you upgrade to TeamCity 9, you could write a scheduled job to run every 10mins (or even every minute) and automatically commit the changes to a new repository. I'd use a new repository so TeamCity doesn't ever try and trigger off the commits.
I don't know what OS or VCS you are using, but you'd just need to commit all XML files so you get project-config.xml, build type XML, and plugin config, you don't want .properties files as the build number files will change after every build.
<TeamCityData>/config/projects/**/*.xml
If you are using Git you could easily just init a repo in the projects directory, add a .gitignore for anything other than *.xml, and run git add . and git commit -m "Build configuration settings were edited" as a scheduled job.
our project structure has been split. On the one hand there is the /plugins folder containing all main plugin projects. On the other hand we have a /tests folder containing all the fragment projects that are the unit tests for their corresponding main plugin projects.
Jenkins lets me check out multiple repositories, and even to the same folder in the workspace.
The problem is that the first checkout is deleted when the second URL is checked out.
/plugins is placed into the workspace directory, then the workspace directory is "cleaned":
Cleaning local Directory .
Then the second directory /tests is checked out.
Of course I want that both folder contents are placed in the same workspace directory. How can I do that?
Assuming you're using Subversion to checkout your projects, you need to specify the "Local module directory" to something other than the default for each path you are checking out.
For example;
If you have svn://myrepo/myproject/plugins and svn://myrepo/myproject/tests, the configuration would be along the lines of;
Modules:
Repository URL : svn://myrepo/myproject/plugins
Local module directory (optional) : plugins
Repository URL : svn://myrepo/myproject/tests
Local module directory (optional) : tests
This would then inform Jenkins that it has two paths to checkout and into separate locations.
If you are trying to checkout a project into the subfolder of another working copy, you may have to use svn:externals on the parent directory.
In the new Jenkins 2.0 pipeline (previously named the Workflow Plugin), this is done differently for:
The main repository
Other additional repositories
Here I am specifically referring to the Multibranch Pipeline version 2.9.
Main repository
This is the repository that contains your Jenkinsfile.
In the Configure screen for your pipeline project, enter your repository name, etc.
Do not use Additional Behaviors > Check out to a sub-directory. This will put your Jenkinsfile in the sub-directory where Jenkins cannot find it.
In Jenkinsfile, check out the main repository in the subdirectory using dir():
dir('subDir') {
checkout scm
}
Additional repositories
If you want to check out more repositories, use the Pipeline Syntax generator to automatically generate a Groovy code snippet.
In the Configure screen for your pipeline project:
Select Pipeline Syntax. In the Sample
Step drop down menu, choose checkout: General SCM.
Select your SCM system, such as Git. Fill in the usual information
about your repository or depot.
Note that in the Multibranch Pipeline, environment variable
env.BRANCH_NAME contains the branch name of the main repository.
In the Additional Behaviors drop down menu, select
Check out to a sub-directory
Click Generate Groovy. Jenkins will display the Groovy code snippet
corresponding to the SCM checkout that you specified.
Copy this code into your pipeline script or Jenkinsfile.
I want to create a new hudson job that pulls sources from two version control system cvs and svn.
Is this possible. I dont want to move from cvs stuff to svn, because we will soon be moving to git.
suggestions?
if you create a 'freestyle' software project you can configure it to use CVS for example.
In the build instructions you add the commands necessary to checkout the subversion sources if they are not yet checked out and update them if they are.
After these commands you add your regular build commands.
Of course the build will only trigger on the configured CVS.
To trigger on both, create a dummy project which checks out the subversion, does nothing, but configure it to trigger the first job.
I hope there are no overlapping folders/files because then you're in for a lot of fun...
good luck!