I have 2 configurations in the teamcity which refer to 2 separate repositories in the mercurial. When starting a build the project updates all its files. Can we configure 1 build agent to have 2 reprositories so that only the changes of the corresponding project are taken and not all files of the project at updated when starting the configuration? Or do we need to create 2 agents?
If TeamCity decided to clean checkout directory on an agent, it should log why this happens into the build log of the build.
Possible reasons of clean checkout are outlined in documentation: https://confluence.jetbrains.com/display/TCD18/Clean+Checkout
I participate in a student project. I want to contribute my (long existing) Netbeans project to the project, so I have to upload/push it to a Github repository (which belong to another participant).
I am new to Github and followed instructions:
https://netbeans.org/kb/docs/ide/git.html
https://netbeans.org/kb/docs/ide/github_nb_screencast.html
The result was that all my code (~40 source files) were uploaded/pushed to the root/origin of the repository, which is of course annoying to other participants.
Now I need to figure out, how to move this code into a subdirectory, and make Netbeans to push changes into this directory henceworth.
So how do I set up a netbeans project to be a subfolder of the repository in Netbeans?
I don't think you can do this with NetBeans. I would suggest to:
Install git bash
Clone the github repository
Create or copy your project in that clone where you like
Open your project in NetBeans for adjustments
What is the set up required to move files between builds in TC? I am needing to move both modified source files and build binaries between the build configurations of a build chain.
I have 1 project with 4 builds. The builds are
Update Version Number (This build updates 15 sources files)
Compile (This build compiles a dozen objects)
Test (This build runs a regression test)
Create Package (This build creates a setup.exe file)
Information about the TC setup and chain
I am using perforce as my VCS.
All 4 builds use the same VCS root.
On all 4 builds under version control settings I have "Clean all files before build" set to "On".
"Update Version Number" build is triggered by any check in to the VCS. (This works)
I have been able to successfully chain and trigger the builds. However each build starts with a fresh copy of files from the VCS.
The chaining is set up to use snapshot dependency.
Based off of the TC documentation it looks like I should be using snapshot dependency and not artifact dependency. If I put the build steps of all the builds into the same build everything works. However we are looking to have more flexibly and expand on this build chain in the future.
I tried setting up the configuration so only the first build is attached to the VCS root and the other builds don't have any VCS root. This didn't work.
I have been unable to find the answer googling but I have been able to find someone else who is struggling with this problem. Sadly they didn't receive an answer.
After speaking with TC customer support I learned the correct technique is to use both artifact dependency with "build from the same chain" selected and snapshot dependency.
Trying to move to the officially supported Golang vendoring solution from legacy Godeps workflow.
Scenario:
Repo A===
\
========> Repo C (shared library code)
/
Repo B===
What is the best workflow I can choose for a mid-size (roughly 5-10 member) team of engineers to vendor Repo C for both Repo A and Repo B? Engineers of varying abilities, most of which probably shouldn't need to know the details of this at all?
I'm currently using govendor for this. I'd prefer not to switch but would if there is a tool that provides a better workflow.
This needs to integrate with a CI server running the builds. I can think of 3 scenarios:
Vendor Repo C into A & B:
Pros:
Reproducible Builds
Easy integration with CI
Cons:
Manual and Error Prone - Can easily vendor incorrect code
Engineers need decent knowledge of vendor tool and methodology
Symlink Repo C trunk branch into vendor folders of A & B:
Pros:
Engineers need no knowledge of vendor tool
Low Developer Maintenance
Cons:
Builds not (easily) reproducible
Possibility of including code in build that shouldn't be released
Less Flexible (Repo A and Repo B can't have differing versions of C)
Include Repo C as a git submodule or subtree in Repo A and Repo B (either utilizing vendor or not):
Pros:
Engineers need no knowledge of vendor tool
Easy Setup
Less Maintenance
Reproducible Builds
Cons:
Having to use git submodule or subtree
Finding surprisingly little about this question on the internet. Is there some idiomatic way of doing this? I'm sure there are other ways of doing this; what am I missing?
i suggest to use a manifest based approach with version constraint.
Project A == Manifest
|- Repo A#~1.0.1
|- Repo B#~1.0.1
Repo A == Manifest
|- Repo C#~1.0.1
Repo B == Manifest
|- Repo C#~1.0.5
Repo C == Manifest empty
Which will resolve into
Project A == Resolved Manifest
|- Repo A#1.0.1
|- Repo B#1.0.1
|- Repo C#1.0.5
where ~1.0.1 means >=1.0.1 <1.1.0.
As you see B and A dependency to C are independent, yet within project they are resolved correctly.
In the event A and B would define incompatible dependency to C, an error should occur as the project should not be build-able.
You may prefer to use caret ^ rather than tilde ~, ^1.0.1 -> >=1.0.1 < 2.0.0.
Note that you are not forced to use those 'helpers' such tilde and caret, you may define explicit version range.
You shall decide which constraint to apply given the level of confidence you give to the remote author to correctly upgrade its version number.
Finally,you can use glide to solve that for you.
Starting with Repo C, assuming you already tagged the repos, run glide init, git commit -am 'glide init', git push
Repo A, glide init, glide get git#repo.com/repoc, git commit -am 'glide init', git push
Repo B, glide init, glide get git#repo.com/repoc, git commit -am 'glide init', git push
Finally, Project A, glide init, glide get git#repo.com/repoa, glide get git#repo.com/repob, git commit -am 'glide init', git push
To re install the project, glide install, go build.
Nothing prevent you to tarball ProjectA with its vendor folder, in order to skip the glide install command when you execute the remote installation.
But you normally don t want to commit the vendor folder for a development environment. You d usually add vendor/ to your .gitignore file and run glide install or glide update.
Expect some difficulties in the begin, passed that step, things will work.
Once you jumped to that workflow, note that you ll have to bump every changes on your repos.
That is bloatware when you work both project A and repo B to reach a viable change, so in that case, rather than vendoring repoB into project A (you can leave the manifest definition, but get ride of the repoB folder into vendor/), install repoB as a go module with the go get command.
Doing so the changes are taken in effect immediately on re-build. Once the change set is completed, browse into each repos and bump them appropriately.
Finally you may want to use a version bumper to help you to get it done quick and fast, it happens i did one for my personal usage.
hope this helps.
We have a maven project for which we have set up jenkins for build. The reporsitory has a large tools folder which i didn't want Jenkins to download.
I just want jenkins to download src folder and pom.xml file.
I added two reporsitory locations in Jenkins - only to learn that Single file checkouts are not possible
This forced me to use shell script option provided by Jenkins for checking out pom .xml . PFB the script outline.
svn checkout $pomUrl . --depth empty
svn update pom.xml
I did not find an option in my scm plugin of Jenkins to do an empty checkout
Checkout one file from Subversion
But POLL SCM of jenkins is only polling the src folder and builds are not triggered if i make some changes to pom.xml. Is there a way to ensure Polling of my pom.xml as well?
No. Jenkins will poll what it knows.
In your scenario:
Jenkins doesn't know about your pom.xml.
Jenkins doesn't work in single file checkouts anyways.
You will have to rearrange your structure, either move the tools folder outside of the main checkout (if it's so large that it's prohibitive, why do you have it in the root location?), or move the pom.xml into the src folder.
Edit:
Here is an idea. Haven't tried so don't know if that will work.
Keep your manual checkout and update of that pom like you currently do.
Setup another SVN Add module....
Enter the root location of SVN where your pom is, give it a non-conflicting folder name
Configure Repository depth for that module as Empty (if you don't see this option, you may need to upgrade your SVN plugin and/or Jenkins).
Click Advanced... section.
Configure Included Regions with the path to your src folder, and the pom only.
Something like:
/trunk/myapp/src/.*
/trunk/myapp/pom.xml