I am automating the build of my .net core solution using TeamCity v10:
lets say i have the following projects:
A -> B -> C ->D
A->D
The arrow indicates that Project B references project A and needs it be restored and built before.
Configuration
Project D is a web application that has to be published at the end (it also needs both C and A)
For that to work I created a Team City project for each of A,B,C,D
Then for each project I created a build definition that consists of two steps restore and build
the restore and build steps specify the project.json file of the specified project (for example in project B case it would be "src\B\project.json"
I added extra step for Project D, which is publish since it has to be published to IIS.
Snapshot Dependencies
Any build on projects that are referenced should trigger build on the dependent projects in order to make sure that changes would not cause other projects to break.
For this case, I created the following snapshot dependecies:
B has snapshot dependency on A and Finished Build Trigger on that dependency
C has snapshot dependency on B and Finished Build Trigger on that dependency
D has snapshot depends on C and A and Finished Buid Triggers on those dependencies
If I trigger a build on A, its triggering another builds on the build Chain (Which is A->B ->C -> D).
Then, If I trigger C, its triggering only D.
However If I start from B, Or C without having done the trigger of A first, the build of B fails since it needs project A Output First.
Questions:
For the build Configuration steps, am i doing it in the right way, taking into consideration that I have other projects (F,G, H) that also refer to A and B.
If need to start building project B, how can configure it to build Project A first, if that was not built before.
The solution is to configure snapshot dependencies from B to A, from C to B, and from D to C. However, the dependency from D to A is excessive, because the whole build chain runs on the same revision.
If build B is triggered, then all build up the chain (A and B) should. There can be an option "Do not run new build if there is a suitable one" enable.
In this case build B will reuse suitable build A, if it exists.
Regarding triggers:
It's not recommended to use finish trigger in this case. To trigger
the whole build chain, then we should run build D, so that it will
add the whole chain in the queue.
To trigger build chain automatically on changes in VCS root,
configure only one VCS trigger in D build configuration with option
"Trigger on changes in snapshot dependencies".
In this case if there are VCS changes in any build (A, B, C or D) the whole build chain will be triggered.
Related
I have projects in many git repositories, starting with the base api and then branching outwards.
When the API materially changes, I want to verify that downstream projects (that use the particular API) work correctly.
I hoped this workflow would be supported out of the box:
Make changes on branch to base API
Create same named branch on a subset of projects that may be affected by the change
Execute the build triggering children with
run-A:
stage: .post
trigger:
project: a
branch: $CI_COMMIT_BRANCH
strategy: depend
run-B:
...
Sometimes I want to verify A, sometimes B, sometimes both or neither.
If I don't have the same branch in A and B, I start getting
Downstream pipeline cannot be created; reference cannot be found
How can I get gitlab to depend on the results of other project builds, but ignore the downstream project if the branch doesn't exist?
I have inherited a collection of Bamboo build plans and corresponding deployment projects. Here is a particular example of how I would like to leverage reuse. We a four deployment projects (say ProjA, ProjB, ProjC, ProjD) that can be run individually/independently. However, we also have a project where we deploy them together (call it ProjABCD). Currently, ProjABCD replicates the steps from the individual A, B, C, D projects and executes them consecutively (e.g., if each has 10 steps, ProjABCD has 40 steps).
Is there a way to have a super-project (ProjABCD) that simply simply "calls" the four individual ProjA, ProjB, ProjC, ProjD? Ideally, this would also be able to roll-back to baseline state if any project in the group fails to deploy properly.
You should be able to come up with a scheme using the triggers functionality. There should not be a need to have a 40 step combined deployment (that breaks a lot of the value the deployments provide). There are multiple ways to solve/simplify this problem. For example you may choose to have two different builds, and only one of them triggers the 4 deployments.
So I'm actively trying to circumvent the job limit bamboo has in place because I have many inactive repositories that get fixed occasionally when new platform updates come out or a one-off new feature is added.
What I would like to happen is for my repository polling to pick up that there's been a change on one of my repository branches, run the job, and presto-change-o we're back to square 1 where I'm listening again for another repository polling update from another change.
Example:
Repo 1 has a commit pushed
Bamboo "hears" the change and starts the job
Repo 2 has a commit pushed
Bamboo hears this change as well, but doesn't continue due to 1 agent being available, this change is queued for later
Repo 1's triggered update finishes and publishes an artifact that can be shared
Bamboo resolves and starts Repo 2's job
Is doing something like this even possible? The best solution (meh) that I've found thus far is to just create one job with a sequential build where it's basically checkout/build/checkout/build/checkout/build but that would result in having to run through many unnecessary steps should I poll only one update from one repository. It's not like these things are changing frequently.
You can add multiple repositories to your build plan, and in your repository polling trigger put checkboxes on all repositories added into the plan.
To add multiple repositories,
Open Plan Configuration Editing
Select third tab "Repositories"
Press "Add repository" button.
Configure your repository and save.
Select fourth tab "Triggers".
Open your Repository Polling trigger and select all repositories you've added on steps 3-4.
Save the trigger.
Then repository polling has to check all configured repos, according to documentation:
https://confluence.atlassian.com/display/BAMBOO058/Triggering+builds
You can also add additional repositories into Source code checkout task, and checkout every repository in different subdirectory.
E.g. for repos R1, R2, R3 you will have working copy directories ./W1, ./W2, ./W3.
And Then it's up to you - either you clone your assembler task T to T1, T2, T3 to make builds from each working copy correspondingly, then it will be done for all jobs on every commit, they will all produce artifacts with the same build number, or you can add a shell script task and write a shell script which discovers the latest commit among all working copies (let's assume it is ./W2), creates symbolic link to that working copy subdirectory as ./MySymbolicLink, and your job that assembles the build will do that from ./MySymbolicLink folder.
I'm wondering if it's possible to use a folder/package/repository in multiple project at the same time without simply copy paste it.
For example :
Project 1 has Package A & B
Project 2 has Package A & C
Project 3 has Package A & D
Can I take the A Package outside of my 3 projects and create a link to this folder inside my 3 packages like a library & look like this
Folder A
Project 1 has Package B and a link to A
Project 2 has Package C and a link to A
Project 3 has Package D and a link to A
So my Package B,C & D that are using objects from A without issue but If I want to make a change on A in don't have to copy/paste or push/pull on the all the other projects that use A
You are asking for code-reuse. The code you put into a dedicated package is some kind of library that you'd like to use in different projects. As indicated in #duffymo's comment you should split this code you want to re-use into a dedicated project, and include this project as a library. For that you can use systems like Maven, or just create a JAR file and manually add it to the classpath.
In other words, before you find a (crude) way to make things work, please take a step back and consider a "good" solution.
my build process with TFS 2010 should perform different task one after the other like:
Build 1st project in solution
Execute MSBuild via command line (to publish the project)
Execute a 3rd party tool via command line (to obfuscate the binaries)
Build a 2nd project in the solution (an InstallShield project)
How can I achieve this? I can define several project in the Build Definition but how can I invoke several command line task between these build steps? And the MSBuildArguments in the Build Definition: Are these arguments for every msbuild call for each project/solution?
Thanks
Konrad
At first, you need to add in your build definition the distinct *.*proj instead of one big *.sln - or (even better) construct more than one *.sln & order them to get build in the build definition. So you could organize a Project1.sln, Project2.sln etc that are only used from the Build.
In addition to that, you would have to make changes in the build process template to get this.By default you get something like that, that executes each set project/solution within a bigger foreach:
A good way would be to enhance this as a sequence, where all your custom action are set as InvokeProcess activities:
Obviously, you would have to insert here a flow control, so that Publish & Dotfuscator execute the first time (where Project1.sln gets build), while ISDEV executes the second time (where Project2.sln gets build). In the sample below I used a switch & packed Publish & Dotfuscator in a new Sequence.
Finally, you would have to have a counter of some sort. The most immediate option is to set a new Int32 Variable with default == 1 and increase it by hand during execution. In the sample below this is done in the lower Assign:
This final override of Complie the Project, along with a changed Build Definition should get what you 're after.
The team build definition takes a list of sln's and msbuild project files. You can put simply split your InstallShield project out into it's own solution ( most developers won't have a copy of InstallShield anyways likely ) and write an msbuild targets file for steps 2 and 3. Then just tell your build definition to build solution 1, the targets file and solution 2.
You could also choose to put the stuff in the targets file in a postbuild event for one of the projects in solution 1.
I wouldn't do this in workflow.