We are looking at modifying our build process so that our configuration files are all template based. We will then have a local.properties.xml file which will be used by NAnt to create configuration files that are specific to the person running the build.
My question is how can I safely provide TeamCity with a file considering we don't want to check in the local.properties.xml? I'm pretty sure that TeamCity nukes the build directory it has so I don't think I can just drop a file in their.
Any suggestions?
I see the hackish way only: post your file as an artifact of some build and retrieve it with help of artifact dependencies.
Related
I want to build my project from TFS Azure(VSTS).
I have made one project which is under Asp.Net Core.
I have made Build definition with Asp.Net Core Template and given the path for restore like **\*.csproj but I am not sure about this path or not?
I have tried many options like **\admis.csproj and some others, but I have faced the same error as the one on the following image:
I am using Asp.Net Core 2.1. Any ideas?
Just check your Workspace mappings in Get sources step, make sure you have mapped the source directory which included the solution or project file *.csproj:
Please check!
1) Server path should be: $/YourDevOpsProjectName/YourBranchName/TheRestPathUntil .csproj file
As I see on your screenshot, your path should be $/0424Test/NetCoreApp/NetCoreApp (I'm assuming that your .csproj file is there).
2) I had the same problem, because when I tried to Queue build for my project, in Source version I set 1 and the process of the queue tried to take 1 source code version, that of course not exists.
If Source version's value is empty, it try to get the last version of your source code
3) Use **/*.csproj as "Path to project(s)" for every task in your Agent job.
Please check!
Server path should be: $/YourDevOpsProjectName/YourBranchName/TheRestPathUntil .csproj file
I would like to understand what role the target folder plays in a SOA MDS project.
I am using JDeveloper and the target folder keeps getting populated with 2 .jar files. I am not sure where these jar files are coming from, but they contain old data which should be changed.
Can somebody please help me understand what is behind the making of these files?
The target folder is the default build output directory used by maven.
If working correctly, the builds should be generated there by maven using the configuration specified in the pom.xml file. In your case, the maven build might not have been run recently, which is why you see old content in the jars.
Have a look inside the pom.xml and see what build configuration has been specified there (it is likely to be no different from a SOA composite maven build file/pom file). If it's all built correctly, you should be able to deploy that jar directly to the MDS runtime (either manually or via maven).
In the pom file, you should be able to override most things there including the name, version, bundle type, target directory etc.
You can also use maven to keep track of your MDS changes - i.e. version it like any other build artifact/SOA composite. The versioned jars can also be uploaded to an artifact repository (such as nexus), in addition to being deployed to MDS runtime, so you have good level of traceability of MDS changes
PS -
This might help explain more: http://weblog.singhpora.com/2016/10/managing-shared-metadata-mds-in-ci.html
I have read articles on build automation and it looks simple, but I am really not sure about parameterized build. I believe, there must be a xml file for that.
When we say build is automated, I believe it means our code/binaries sit in test environemnt. And all application related settings will also configured just by simple clicks of build, and push.
What are the required tools? What is MSBuild ?
Please put some light on it.
MSBuild is and exe that you run with command line tools and pass to it the project file (.csproj) which is an XML file as you said and it has all the instructions needed as you configured.
I created a series of videos that describe how to create simple MSBuild tasks and how to organize tasks and so on, for more info click on the following link:
MSBuild Tutorial
MSBuild is exe
When you run MSBuild from Command line
You will need to unload the projct so you can edit the (.csproj) or project file
The (.csproj) or project file
You are asking about build automation, and by your tags you menation TFS 2010 if so then you only need a cursory understanding of msbuild to get started. It is what eventually calls the compiler, but in all hoensty you need the step above it which are the build templates and defintions, along with how to set up agents and controller.
Here is a good overview document by Martin Woodward, this should give you enough to figure things out, or ask more specific questions
We've got an Asp.Net web application we're trying to get pseudo-deployed to a folder, and I'm starting to think Microsoft are crazy -- why is it so hard to get a WAP to do a "Local FileSystem" deploy as part of MSBuild?
I can build with this:
msbuild .\SubSite.csproj "/p:Platform=AnyCPU;Configuration=Release" /t:Package
And get a nice package.zip which I can deploy to a website...
However, I have two projects in my solution, which I need to combine before I ship them, so I want to deploy both packages into a folder, and then re-package that folder. Despite the documentation on technet to the contrary, it doesn't seem to be possible to do:
msdeploy -verb:sync -source:package=.\SubSite.zip -dest:contentPath=.\Www\SubSite
Because you get the error:
Source (sitemanifest) and destination (contentPath) are not compatible for the given operation.
Does anyone have a suggestion of how I could web deploy two sites inside one another without manually copying files out of a "PackageTmp" folder? I mean, I'm aware that I could just skip zipping the package and manually copy the files out to do this, but I'm not happy about having to create a custom target, and there's no other way to find that just to do something that should be built in.
We did eventually figure out how to do this, but I'm not really happy about it ;-)
Basically, (as mentioned elsewhere on so), you can call msbuild with the target set to _WPPCopyWebApplication. You can also specify/override the WebProjectOutputDir property when you do that. Something like this (where ${name} are variables we're using)
msbuild ${SourcePath}\Www\UI\UI.csproj "/p:Platform=AnyCPU;Configuration=Release;WebProjectOutputDir=${OutputPath}\AppRoot" "/t:_WPPCopyWebApplication"
msbuild ${SourcePath}\Www\Mobile\Mobile.csproj "/p:Platform=AnyCPU;Configuration=Release;WebProjectOutputDir=${OutputPath}\AppRoot\Mobile" "/t:_WPPCopyWebApplication"
msbuild ${SourcePath}\Www\Service\WebService.csproj "/p:Platform=AnyCPU;Configuration=Release;WebProjectOutputDir=${OutputPath}\AppRoot\WebServices" "/t:_WPPCopyWebApplication"
We can then package up the whole "AppRoot" in a separate step.
If you have a project that builds one project before building the next, but the next needs to know the 'path' of the first build, is it possible to get this?
For example:
Project A has Build Configuration A and Build Configuration B.
Build Configuration B has a dependency on Build Configuration A. From without the Build Configuration B it will need access to the path of Build Configuration A. Is there are a way to obtain this?
Most simple approach would be to define a custom checkout directory in the A and use the same hard-coded value in B.
If you use TeamCity snapshot or artifact dependencies, you can use %dep.btXXX.teamcity.build.checkoutDir% to get checkout directory of the dependency build. However, this will not work in 6.5.0-6.5.5 TeamCity versions, see details and workaround in the issue TW-18715.
However, you should really avoid accessing checkout directory of one build from another. If you need sources of A, you can checkout them in B; if you output of the A's build, then publishing the output as build's artifacts and then using TeamCity artifact dependencies is the way to go. In both cases additionally using TeamCity snapshot dependencies will ensure both builds use the same sources snapshot which is probably what you need.
If you have one agent, and only ever one agent then you could try and use the path from a previous build.
I wouldn't recommend doing this however because if you had two agents, or scaled up in the future to two agents, then it is possible your projects will be built on different agents; this would mean your dependency working directory won't be on the same machine, or it will be outdated as the latest was built elsewhere.
I assume you're after the path of the first build to get its output?
If so, the method we use to share dependencies between projects is to checkin the output from each project into our source control, then every project that requires the output simply has to check them out.