Add files to TeamCity artifact zip - continuous-integration

We are using TeamCity as CI and we are struggling with the final build step: We pull a dependency from another build step (a zip) and want to add a few extra files. Do we really need to extract the zip (quite large file), copy the files over there and zip it again? Is there support or a plugin to add files to existing zip files?

TeamCity itself does not support this and I haven't seen any related plugins, however, if you really need to wait until the final step to add the extra files (maybe you are doing some kind of file generation at this point), then I would recommend using something like 7Zip.
you can update existing zip files (assuming they are not "solid" archives") with a very simple command:
7za.exe u targetZip.zip file.ext
this will add "file.ext" to the zip file "targetZip.zip" without decompressing and re-compressing the archive.
you can find 7Zip here: http://www.7-zip.org/

It would be much better to include those files at the previous step, which lists which files should be included to the final artifact. Rather than trying to modify the already generated artifact. So basically all you need is to add an additional build step that will simply copy those other files to the output folder from which you are producing your final artifact.

Related

Maven: how to copy a directory cleanly before creating the JAR?

I want to store some additional files in the JAR that gets created. Those files are in a directory that is a subdirectory of a repository which is pulled in via a git submodule.
I want to copy that submodule to my src resources directory before compiling, but I also want to make sure that any old files at that location are removed first.
How can that be achieved best with Maven plugins? I did not find any option to remove any destination files with the copy-resources goal of the maven-resources-plugin and I could not get the maven-clean-plugin to run right before the copy-resources either. So how does one accomplish such a trivial task with Maven?
UPDATE: as mentioned above, the reason why I want to do this is because what is copied should become part of what gets added to the resulting jar (and could potentially be part of what gets compiled). So I need to copy these files into the src directory and NOT the target directory. What should get copied before each build is the input to the build, not an additional output.
There is one flaw in your approach, and it probably explains most of the obstructions you encountered.
During a build, the only directory in which you may write is target. Copying files to src or changing them is strictly discouraged.
The target folder is erased by clean, so no need to tidy up yourself or to manage old files.

Get tarball from .tar.gz archive in gradle

I have some .tar.gz-Archives and would like to only unpack the Tarball to create a sha256-checksum hash of the .tar-File. (The reason for this is that the archive will be un- and repacked later on, as we are generating patch-files.)
Now this seems like an easy task but I'm stuck. There are either Gradle examples for:
getting the unpacked tarTree (with a Gradle Copy-Task and tarTree(resources.gzip('model.tar.gz')) (from documentation: working with files)
unzipping Files (with zipTree), which does not work with gzipped files
Both approaches do not work, since I need to create a checksum of the .tar-File itself. Unfortunately I can't use commandLine or gunzip as the tasks should run on both Windows and Linux.
The only solution I can imagine of right now is unpacking the tar.gz to a fileTree and repacking it to a tar-file, but I'm not even sure the checksum would be the same.
Is there really no way to do this directly?
Finally I got it to work with help from a colleague.
Using resources.gzip(), which returns a ReadableResource, we can copy the resulting InputStream into a .tar-file with IOUtils.copy:
file("test.tar").withOutputStream { outputFile ->
IOUtils.copy(resources.gzip(file("test.tgz")).read(), outputFile)
}
We also needed to add Apache commons ("commons-io:commons-io:2.6") as a dependency.

How to make a Zip Backup in TFS Build Definition Before Pushing New Changes

Before using xcopy feature of TFS 2017 Build Definition to push new changes,I want to take a Zip backup what is there so that in case I need to rollback.I can simply use that.
How can i do that. Which task i need to add in Build Definition.
You can use the Utility: Archive Files task to zip the files. Just set the correct root folder which you want to make a zip.

File Content Replacer having no effect on artifacts

I'm using a relatively new feature of TeamCity: File Content Replacer. In my current setup I have a version.js file in my VCS:
window["MyPlugin"].version = "1.0.##VCS_REVISION##.##CI_BUILD_NUMBER##";
I use the File Content Replacer build feature to replace that last part with:
%build.vcs.number%.%system.build.number%
So far so good!
I have one relevant build step. It's an MSBuild step, but it does nothing except call a ps1, which does two relevant things:
Moves all js files to an "output" folder;
Zips all js files into a "zips" folder;
Those are also my two artifacts (an output folder, and a zip file).
However, the File Content Replacer reverts its changes, but this revert is also reflected in artifact nr 1, which are files that are not under version control (even though they are located as a subfolder of my project folder). The version.js file in the zip file is not reverted.
If I change artifact 1 to be my/output/folder => all.%build.vcs.number%.zip then the zip file will also contain a reverted state instead of the output I want.
How do I set TeamCity up so that the artifact files are not affected by this revert? Or do I need something other than this Build Feature?
I'm using TeamCity 9.1.3 build 37176 running on Windows 2012 Server (VM) and the default database for evaluation purposes. I'm using TFS 2013 as my VCS.
PS. I've also asked about this on the JetBrains forums.
File content replace reverts changes before "Publishing artifacts" stage. This is "by design". You can check it in the build log. However you can find modified files in hidden artifacts .teamcity/JetBrains.FileContentReplacer/.
If you want to publish changed file as regular artifact you should create a copy of the file (or pack/archive it as as you've already done). Also instead of using File Content Replacer build feature you can create a script that would make needed changes which aren't reverted.

How do I download an artifact from an archive in TeamCity 6.5? I can't construct the correct URL

I have a zip archive artifact. I'm interested in downloading a single file from that artifact. I can't upload that file outside of the archive right now. The documentation says you download an archive like this
/repository/download/BUILD_TYPE_ID/BUILD_ID:id/ARTIFACT_PATH
So, my URL for that looks like this (and I need anonymous access, so you see the guest flag). And it works!
/repository/download/bt23/2253:id/mypackage.zip?guest=1
However, I want one single file from that artifact. And the docs are confusing on how to do that. They do not specify what replaces <zip or jar archive>. And I am not constructing the whole buildNumber or buildTypeId values properly.
/repository/archive/<zip or jar archive>/buildTypeId/BUILD_TYPE_ID/buildNumber/BUILD_NUMBER/index.html
I tried using zip and `.zip'. I tried filling in the build values directly, but it's much different from the working archive download URL.
/repository/archive/zip/buildTypeId/bt23/buildNumber/2253/myfile.txt?guest=1
Does anyone have working concrete example of the URL for a single file in an archive?
You need to replace <zip or jar archive> with relative path to your artifact. For example, if you want to retrieve file.txt from package.zip which is uploaded under dist directory in your build artifacts you need to use this url:
http://server/repository/archive/dist/package.zip/buildTypeId/bt23/buildNumber/2253/file.txt?guest=1
BTW, a new, more straightforward URL syntax will be available in TeamCity 7.0:
http://server/repository/download/bt23/2253/dist/package.zip!file.txt?guest=1
Old URLs will be supported too.

Resources