Publishing GulpJs minified/concatenated javascript via MSDeploy and Teamcity - asp.net-mvc

Apologies if this question has been asked before. I have found variants on this theme but nothing that seems to fit our particular configuration.
We have developed a custom GulpJS task which parses a .json file located inside our folder assets/javascript. This json file contains an array of relative paths to javascript files (both our own and library) in a specific order for minification. They are then outputted to the folder assets/javascript/build and concatenated. The javascript source files are in the project but the minified and concatenated versions of the scripts, in fact the entire build folder itself, are not included in the Visual Studio project.
Ideally, I would like to have a step in the MSDeploy configuration which would copy all the files in the javascript build folder to the destination. Otherwise I could potentially include another step in Teamcity to do so.
Has anyone successfully instituted a similar build configuration and could share some insight? I tried using the MSBuild copy task but that didn't seem to copy the files to the output location. One option that I am considering is including the minified scripts in the project file but this might potentially trip up other developers who don't have Gulp running in their development environments (hilarious as that might be)

Related

Building a non-uberjar Docker image with leiningen

I have a clojure project that depends on a Java library, that does not work, when it gets included in an uberjar. (It needs different XML descriptors using the same filename in different JAR files.)
Everything I find on using Docker with leiningen depends on building and packaging a uberjar. That's also how I built all clojure Docker images so far.
Is there any leiningen plugin out there, that understands to package a Docker image using several jar files like io.fabric8/docker-maven-plugin does?
Whenever packaging (uberjar, war) the big file that is created contains .class files and a directory structure. Where are these XML files supposed to be (class)loaded from? You can experiment with packing manually. After all it (whether uberjar, war or jar) is just a zip file.
When you know exactly the layout you need SBT is flexible enough to insure you can package from the many input jar files. Unfortunately lein plugins will do things like always overwrite duplicates, and you can't control the packaging behaviour. I can't remember exactly the inflexibilities, but I couldn't control how the packaging process went, what decisions were made.
For doing it manually I use a Linux something called Archive Manager, which I found to be much better than what I used when on Windows. Doing it manually may be all you need. The downside of SBT of course being that you have to learn it, which includes a bit of Scala.
It needs different XML descriptors using the same filename in different JAR files.
Just thinking about this, is it that you need to append the contents of each file that is in a different jar into the one file that is in the uberjar? You can try it out. If it works and you need to package up often enough that manually creating and renaming a zip file every time becomes a pain, then I believe that SBT will be your best bet.
I have to package my container with the original jar file and then reference this jar in the classpath when starting the application
The classloader loads classes rather than jars. It is the container's job to unpackage all the things you give it, such as .class files, (uber)jars, wars. Any program that dynamically loads from the classpath is loading either classes or resources (things like .xml files). I suppose a .jar file could be a resource, in which case you would put the jar file in the uberjar. So it is still possible to package it up.

TFS Build single folder not being copied

when building my app on a TFS server, a single folder (with 2 .xml files) aren't copied to the output folder, but all others are.
These files are: a normal xml file and it's tranform version,
This is on the corporate TFS build server and it works for all other files / transformations. So it must be one of my settings in this project / File.
I've checked the files, it's set the same as a .css file that is getting copied (so set to content)
anyone has an idea where I could have a look to find why this is happening?
or even better has a solution for me.
Found that WIX was removing this file

Release manager for TFS 2013 app.config processing with token files

I seem to be getting a lot of pain with the processing of app.config and token files (we have this working with the older ".11" templates).
It looks like currently (using the ReleaseTfvcTemplate.12.xaml) this is running the tokenisation after the build.
While I can make the app.config / myapp.exe.config stuff work by deliberately copying the .token file into my output folder (so the recursive search finds it) this feels pretty horrid.
As a fix I'm tempted to move lines 182-230 to just before the RunMSBuild task on line 175 (creating a new sequence at that point)
Is this the correct approach or have I missed some documentation somewhere (or a later version of the template?)
Thanks guys... Anyway for future reference I did make the change.
However I had misunderstood the exact nature of the order things happen out of the box which is as follows:
Get the project out of source control
build with msbuild
Copy the .config.token file over the .config file. This is in the TFS template
As part of the deploy to a server then the token entries in the .config files are replaced. This is in the release manager template.
Tests are run in the msbuild binary output folders.
The problem is this doesn't really work if you're using an project type that uses app.config file as the msbuild process renames these output.exe.config during the msbuild stage so you need to create both an output.exe.config (marked as copy to output) and an output.exe.config.token so when the post deploy is the final output gets configured correctly. This also a problem if you want to tokenise some mstest dlls as these typically use an app.config as well. Basically this is a bit of a mess unless you are using web.config.
We worked our way around this by using the modification I suggested above (you need to create a sequence at line 175 and move lines 178-230 up into the sequence, this is GetBuildDirectory variable bits and the if statement) followed by adding an additional deployment stage which copies back onto the build server with the new tokenised files so the mstest can run against them.
So our new process looks like this:
Get the project out of source control
Copy the .config.token file over the .config file i.e app.config.token copied over app.config
build with msbuild (this means we end up with tokenised myapp.exe.config and mytests.dll.config)
As part of the deploy to a server then the token entries in the .config files are replaced. This is a release management step in the release template.
Deploy the tests back into a folder on build server (think this has to be a fixed folder until update 4 of release manager is deployed) the token entries in the .config files are replaced (so our integration tests can use the newly deployed servers). This is a release management step in the release template.
Tests are run in the fixed folder on the build server (rather than the msbuild output directory) so the test wildcard needs to be changed in the tfs build template.
Quick final note we don't use that build directory variable and it's left at blank I'm not convinced this would work if it was set to a value...
The replacement of variables in config files with Release Management happens at deployment time and not at compile time.
When RM deployes your app it inserts the correct variables.
It sounds like you're hitting one of two issues:
You need to include the .token file in your project and make sure it's set to Copy Always, so that it gets copied to the build output folder.
If you're building a web application, I've seen a bug in the release build process template that doesn't touch the contents of the _PublishedWebsites folder. I don't know if it's been fixed in Update 4 or not, but it was definitely still a problem in earlier versions.

Teamcity is not copying all the folders

I've now setup a MSBuild script to create the folders and files I need in the right structure for my MVC project. I'm then setting Teamcity up to look at the folder with only the files I want to have and copy that to the artifacts folder. So far, so good!
However, There is a few folders in the structure that are empty, and Teamcity does not copy these folder, even if I've set it up to copy the mainfolder and everything in it.
Is there a way to force Teamcity to copy everything - and by that I mean EVERYTHING in my folder, or does it simply not work?
Teamcity Artifact path settings:
Website => Release
You may find your answer in this post : How do I exclude the contents of a directory but not the directory itself in MSBuild
It's not Teamcity but still MsBuild. The problem is that msbuild's include does not include empty directories...
We manage to work around this and skip the empty folders. Therefore this was no longer an issue. However, still don't know how to copy empty folders. My understanding from doing research for a long while now is that it simply doesn't work.

Is it possible to access files stored in TFS’s source control from the TFSBuild.proj file before the “Get” build task?

I’m using a few custom MSBuild tasks that are checked into source control. I would like to import these tasks into my TFSBuild.proj file that TFS uses to build the project. Right now I have created a 2nd project file that includes all of the uses of these custom tasks. I do this because I can run this project file after the workspace has been created and the files have been downloaded.
Is there a way to reference the files on the server from the build project so that I don’t have to do this 2 step process?
I wish the following would work.
<Import Project="$/My/Server/Path/Custom.tasks.targets" />
This question is related to another question. In my case the tasks are checked into source control so that the build machines don't have another required install. Placing the tasks locally doesn't work very well in this case.
If you put the tasks and the .targets file(s) in the same version control folder as your TFSBuild.proj file (or in a sub-directory beneath it), TFS Build will download all of that content to your build agent prior to kicking off your build script.

Resources