I have two teamcity configurations one becoming my common helpers and reuseable components and my other a website which uses the common project.
I use a third configuration to publish to a test environment.
When the third configuration is run i would like it to get the artifacts from the common project and merge them with the website output and deploy. Am i asking for two much?
This ought to be pretty straightforward.
On ThirdConfig add two artifact dependencies. One whose source is CommonProject, and another whose source is WebProject. When configuring an artifact dependency it will allow you to specify which artifact files are are actually pulled from CommonProject and WebProject into ThirdConfig via the 'Artifact paths'. The artifact files can then be placed into some new folder hierarchy specific to ThirdConfig by using the 'Destination path'. These two options ought to be enough to create the directory structure that is the merging of CommonProject and WebProject. That takes care of the merge part.
The deploy is a bit more tricky. To my knowledge TeamCity does not support any sort of 'copy or upload to external location' function out of the box. For this bit you'll need to create an msbuild script (or batch file, or anything that can be run from the command line). Said script can expect the file/directory structure you've created via artifact dependencies where the root of the structure is the initial working directory of the script, and need only push these files out to your specific deploy location. That 'push' of course is going to be specific to your environment. Ftp, unc share, etc.
Related
I'm looking for a way to control versions of my project through IntelliJ. However, I know Git can manage it the best way and I already did started experiencing Git with the help of Madara Uchiha's Git tutorial. I must say it is incredibly useful, but I rather have version control arranged on my harddrive which is constantly backed up.
I decided doing my version control manually and it's pretty slow and annoying. Is there an easier and more efficient way to clone the current project files in another folder?
For example, clone the current project files on another folder named v1.4.2 outside my project structure without relocating my project files, also having them refactored as project on its own so they be runnable whenever.
Set up a local Git repository for the project. It will start with a master branch. Then create a working branch that you make your changes in. You can merge this branch back in to master as you are ready. You can create as many branches as you need and switch between them very quickly. All using the one directory.
If you are new to git you can use something like Sourcetree - (a GUI for Git) it will allow you to manage the repository. It makes it really fast to switch between branches of your repository. It also helps with pushing changes to another location. GitHub, Bitbucket, etc.
For backup, you could always set up the project on Bitbucket. You can create public and private repositories for free. I really recommend setting this part up.
Depending on the environment that you are building on, you could build a shell script / batch script that would copy files to the duplicate location. Without knowing what type of project you are developing in/for it is hard to say what would be the best strategy.
Ideally if your project has a build output you could have the compiler/IntelliJ IDEA place the results into your result folder. You could then copy the results to your Builds/v1.4.2 folder or wherever. Whether you check in the files that are built will depend on your project. You can always exclude files/folders like your ../Builds that you don't want to track via your .gitignore file.
I want to set up my HelloWorld intellij-erlang project with all files in the same directory so I can easily switch between IDEA and emacs/vim.
<my-project>/hello.erl
<my-project>/hello.beam
Now, if I configure the output directory to be the same as the source, hello.erl gets emptied as part of the build and the compilation fails.
I assumed it's something to do with copying resources to the output directory, so I've configured intellij-erlang to exclude *.erl from the resources with a !?*.erl pattern, but this does not have any effect, hello.erl still gets emptied before the compilation takes place.
As an experiment, I've also tried using separate src and out directories, and intellij-erlang always copies the *.erl to out irrespective of the resource patterns.
Based on all this, I would conclude that intellij-erlang cannot work with all files in the same directory. Have I missed anything?
Erlang programs should be build on standard OTP directory structure. Build tools like rebar (used by intellij) or erlang.mk build on this conventions. And so should all IDE's.
Intellij does it, just like you notice. And so does Emacs's plugin (that I use and can confirm). I would guess so does Vim's one.
So if you would like to be able to switch easily between your IDE's you should try to keep to this convetion of keeping you source files in src and compiled files in bin (and headers in include).
I'm following the tutorial for http://mscrmshop.blogspot.be/2012/03/how-to-use-crmsvcutil-improved-version.html on autogenerating an XrmServiceContext file for Dynamics CRM 2011 development.
I have a solution with 3 projects. Each project has a slightly different namespace, depending on whether it's for Plugins, Workflows or the web portal. They all share the format company.software.productversion.module, and only module is different. I want to generate 1 file for each project and put them in the appropriate folders, but I only want to build this project once every time I change my CRM configuration, after which it builds 3 context files (1 for each namespace) and places it into the correct folders.
Is there a way to configure the config file for this project so this happens automatically?
There are multiple ways to do this. Probably the simplest is to have three different folders, each containing their own CrmSvcUtil and their own config file. Then in your Post Build Command line (or if you want to run it manually create a batch file), enter the paths to your 3 different CrmSvcUtil's:
"$(TargetDir)\Project1\CrmSvcUtil.exe"
"$(TargetDir)\Project2\CrmSvcUtil.exe"
"$(TargetDir)\Project3\CrmSvcUtil.exe"
Each one will run by itself with it's own settings, and can output it's own context file.
I have one simple plan with one simple job.
Tasks:
Source code checkout
MSBuild
Run tests
Generate test report
In four steps, my utility generates a test report with screenshots. The report contain absolute links to images. (for example: onclick="window.open('./Screenshots/66ef3a03-8b82-4b40-b49d-b0155e273738.png');return false;").
If I open the report on my local machine, the report works fine, but on Bamboo I receive the error "Page Not Found", because Bamboo has not collected "Screenshots" folder.
How can I set up the Artifact Definition to collect folder with files?
P.S. I tried to set the \*.* copy pattern, but Bamboo collected only files (without folders and subfolders)
You just have to give the folder Location, like "build/", for instance, and then, in the Copy Pattern you can put **/*.* That should copy all the files you want.
Please note that:
The location is relative to the build directory. Do not use the absolute path to refer to the location.
Asterisks are not supported for Location. For this field, provide the folder name where the file would be located.
Plus, you can define as many Artifact Definitions as you want.
The best way of doing this is to zip all you artifact together. I created a bash script to do this
cd "toArtifactFolder"
zip -r Artifact .
Then in bamboo project settings you have to edit the Artifact and changed the location to where ever the artifact zip file is
Then in the Copy Pattern just enter the zip file eg Artifact.zip
Bamboo uses the "Ant file copy pattern".
Matching recursively against all files: **/*
This does include almost everything
Unfortunately this does not include dot-files, at least in my test on a linux build agent. I could not find a workaround apart from a second artifact (pattern **/.*) or the creation of an archive.
Matching against all files in any subfolder: */*
This does not include foo/bar/test.xyz
This does include both foo/test.xyz and bar/test.xyz
You can do more advanced matching; e.g. you can use build/**/*.jar to copy all jars from a build directory.
For further info see the docs
I have a project where I create a JAR which contains a bunch of classes with main() plus a set of scripts which set the environment to invoke them. Most of those are long running processes which log a lot (~10-20GB).
This means I have a pretty complex log4j.xml file which, being in src/main/resources/, goes into the JAR. When something breaks in the production system, I'd like to modify the logging on the fly for a single run.
So I came up with the idea to have a conf/ directory on the production and put that into the classpath, first. Then, I thought that it would be great if M2 would put the config files in there (instead of the JAR). But that would overwrite any manual changes during an automated deployment which I strongly dislike. I'm also not fond of timestamps and things like that.
So my next ideas was this: M2 should leave the config files in the JAR but create copies of the files with the name *.tpl in the conf/ directory. The admin could then copy a template to the basename to override the files in the JARs. .tpl-Files would be overwritten but that wouldn't hurt. Admins would have full control over which version of the log was active and they could run a diff to see whether any important changes were made.
Now the question: Has someone seen a plugin which automates this process? That is which creates a conf/ directory with all or a selected subset of everything in src/main/resources/ and which renames the files?
Best practice in Maven handling config files is to place them in a separate conf directory, and pack them in a binary assembly using the assembly plugin. Placing configuration files, like log4j.xml in the src/main/resources doesn't make sense, since it is not a true application resource, but more of a configuration file.
We cope with the overwriting, by packing the configuration files with the posfix .def. For example: myapp.properties is packed into the assembly as myapp.properties.def. When the person who uses the assembly unpacks it, it will not overwrite his original files. After unpacking he simply merges them by an external tool (we use meld in Fedora Core).
I may be missing something and this doesn't answer directly the question but did you consider producing a zip assembly of the exploded content of required artifacts (to be unzipped on the target environment)?
Sounds like you're attacking the problem the wrong way. Why not just run the application with -Dlog4j.configuration=/some/where/my-log4j.properties? If you want, you can add a command line flag to main() which invokes the PropertyConfigurator directly.