Hi I have a SVN repo with around a 100 projects/apps (maven projects). All of them are totally independent and are build and and deployed in the same way. Using Bamboo can I (using one build plan) build only the the latest updated projects(from the last commit in the repo) or must have a separate build plan for each app.
Both ways are correct. It depends more on infrastructure setup. Do you deploy all 100 apps on same server and same directory? How similar are all 100 applications? What are future plans? Are you planning to move to Git in future? Are those 100 projects planning to be totally different in few months? If you don't foresee any change in next 4-5 months then you can have one build plan and pass app/project name as parameter.
Related
I'm trying to setup a pipeline for running all kinds of tests against pull requests into my repository. Repository is git repo hosted with Bitbucket Server and TeamCity is Enterprise 2019.1.5 (build 66605). There are a few key aspects to the task:
There's a lot of tests. One way or the other tests should run in parallel to achieve reasonable execution time. The tests are already partitioned as separate TeamCity build configurations, each having good enough execution time.
There's much less build agents available for the task, so it's not impossible for a particular build to spend quite some time (up to 1-2 hours) in a build queue.
The result of the testing should be reported to Bitbucket as a single aggregate value. I.e. if there are, say, 3 individual builds from p.1 with two passing and one failing then Bitbucket should receive single "failed" build status.
Ideally, pipeline should be triggered by a feature branch change (refs/pull-requests/123/from in Bitbucket lingo), but checkout merges of the feature branch into target branch (refs/pull-requests/123/merge in Bitbucket lingo).
Given above requirements, I experimented with Composite Build Configuration (https://www.jetbrains.com/help/teamcity/composite-build-configuration.html) as it seemed perfect fit for the job. So I set up single composite build with proper builds from p.1 as snapshot dependencies, "Pull Requests" and "Commit status publisher" build features. It works perfectly, except for one thing...
The only thing I cannot seem to be able to work around is the fact that VCS roots in the dependencies collect changes when the build chain is added to the build queue. This means that because of p.2 (non-negligible max time spent in build queue) some builds end up running against a little bit dated sources. Ideally, I would like to be able to run the builds against the latest sources.
So my question is if there's any way to disable revision synchronization for dependencies? Or maybe I could approach the whole problem in some completely different way without using snapshot dependencies?
Cross-posted at community forum: https://teamcity-support.jetbrains.com/hc/en-us/community/posts/360006745840
I have CI setup with a few C# applications for service fabric.
I'm running the SonarQube scanner on a few projects with my CI tool, but I would like the data to be aggregated into one project in SonarQube, and have it separated by sub-folder/"component". However when I try to push results to one project, it just wipes out all the previous history of the past project.
For example I want my single sonarqube project to look like:
SonarQubeProject
-- serviceProject1
-- serviceProject2
where project1 & project 2 are analyzed separately. Is there a way to do this?
SonarQube 6.7 will introduce the concept of "Application"s as a paid feature (part of the "governance" plugin). This feature will allow the user to group several SonarQube projects into a bigger application.
With Docker you deploy one image under several more or less volatile tags, e.g.:
hash
v1
v1.1
v1.1.1
latest
Is this possible and conceivable for artifacts in a Nexus repository (at least BUILD123 and latest-SNAPSHOT)?
We are providing services other teams are using. Some consumers of this services want to develop against a latest-and-greats version of this service, some others want to develop against a certain build of this service.
Of course we could change the artifact version in the pom.xmls, create Git-Tags for this and build these tags, but this information has no value in the Git repository.
The idea is Jenkins checking out the development branch, building it and pushing it to the nexus repository with a SNAPSHOT version as well as a distinct build version, so consumer can decide wether or not to develop against a fixed build or not.
Is this possible with only 1 deployment resulting in 1 file in the nexus repository (just like Docker)?
At current time this is not possible. We have some plans for the future with tagging, but nothing concrete as of yet.
You might be able to hack something together on the client side that essentially builds things multiple times and then deploys multiple times with different versions. But imho you are trying to hack around instead of really cutting releases treating them as such and really having a SNAPSHOT dev version.
We have several projects undergoing, and there are dependencies relationships among them. All projects makes up a final software.
We set up a DEV build environment to do snapshots build by using LASTEST dependencies. Any change will trigger a snapshot build (jekins job) and all dependent's snapshot build will be triggered too, and so if any changes break some project, that project's own build will notify the owner.
The question is about the release. The DEV build is continuous, and we want to release EVERY project against certain timestamp when it was a GREEN dev build across all projects.
How to get such release process setup?
thanks.
jenkins provides some Post-Build-Actions. You can use them to publish/archive every successfully built artifact to whereever you want.
Your Release-Job can take all the artifacts and deploy them. So you're sure all artifacts are from GREEN builds and is also independent from all the continuous jobs.
If you want to be really cool, do some smoke tests (e.g. is database connection working, external APIs working, etc) in the Release-Job as well.
best,
marco
We're currently using CruiseControl.NET as a continuous integration server for a number of ASP.NET web projects, but we're also evaluating TeamCity.
This is working great for our build server.
What we'd like to setup is a customer facing test server. I'm thinking that when we are happy for our latest development version to be released to the client for test, we could label it in SVN.
I'd then like a second build server to build this version ready for the client to see.
The question is this - is there any way to get either CruiseControl.NET or TeamCity to build only the latest labelled version of the code in a repository?
If anyone has any alternative suggestions, that'd also be greatly appreciated!
You could have a designated location or branch in your subversion repository e.g. \release then point the second TeamCity build server at that.
When your are happy with trunk then overwrite the existing location. The second build server will pick this up, build it, and even deploy it to a test server.
I don't think there's a way to do this directly in TeamCity. You can however configure your build trigger to filter on files and/or users. So, if you touch a given file to indicate release status in addition to or rather than labelling, you can use that.
The trigger filter could be, for example (untested):
+:/ReleaseVersion.cs