Sorry on the delayed response; PG-1472 should fix the version selector failing for packages with partially missing snapshot metadata, like maven-archetype-plugin, which was used to test.

Hello Rob, I've released version 1.0.1 of the TeamCity extension, which should fix this (or at least give a more sensible error message). It should be available in /administration/extensions.

Yes, if you create a Artifact Retention policy with these options: Only purge artifacts in deployed releases Only purge artifacts in rejected packages

There is a DoNotClearTarget option on the Deploy-Artifact operation that, I believe, will accomplish what you are looking for. We don't have masking (which would allow you to deploy only some files out of an artifact), but you certainly could deploy the artifact to the working directory, then copy or transfer files to the target.

The FTP extension can help with this

Hello Charles, upack pack expects a directory, not an individual file, so the command should be: upack pack C:\location_of_upack_json_file C:\directory_containing_my_setup_exe --targetDirectory=C:\mytargetDir\build_artifacts

Well, the only code path that will yield that error is if System.IO reports that the file requested is not on disk. The most likely cause of that is that the file is not actually there at the time (obviously), but that might be because anti-virus quartanteed it, a file server didn't replicate it, or something? So, I would try to find what might be causing that file not to be there. The only way that BuildMaster will delete a file (but not the record) is a retention policy.

Tod - thanks for the reply. We would definitely be interested in this feature in an upcoming release. Thanks.

Thank you very much! The 'Imported Deployables" functionality worked like a charm :-) Regards, Francesc

In v4.8, you can set up a Retention Policy or go to Admin > Administrative Edits and purge an artifact. In v5, you will be able to do the same, but purge the artifact directly from the Release Package ("build") page. // I've updated the old question you linked as well

Alana. I have made a pull request https://github.com/Inedo/bmx-windows/pull/30 Thanks for pointing me in that direction. It was indeed very easy to modify the codebase.

Hi Simon, The variable matching isn't taking place because you're using the simple syntax (see "notation" under Variables Documentation). Specifically, BuildMaster is looking for a varaible named "DeployableName_", which doesn't exist, and thus it is replaced as a literal. So, either change to "$DeployableName-$BuildNumber" or "${DeployableName}_${BuildNumber}". Alana

This sort of workflow isn't really support; the standard way to do this is to re-execute a previous release's promotion to Production, thereby setting the context for the artifact to that of the previous-deployed build.

Thanks Tod, that's exactly what I needed. Works like a charm. -Tim

Interesting, it looks like the unzip program is returning a non-zero exit code, which causes the SSH agent to interpret the command as an error. You might be able to get around this by editing that specific Deploy Artifact action to treat errors as warnings. Also as a workaround, you could deploy the artifact to the "CurrentDirectory" on the BuildMaster server, then use the Transfer/Synchronize Files action from the CurrentDirectory on the BuildMaster server to the Solaris server.

[3] – yes; I'm currently doing the following: Create an application package (by using the standard "Package" target in my "Build .NET MSBuild Project" action) Create a BuildMaster build artifact (i.e. create an archive file containing the application package and ancillary files) Deploy the build artifact to a folder on the build server. Run Web Deploy (msdeploy.exe) via a "Execute Command Line" action to deploy the application package (in the folder to which the artifact was deployed in [3]) to the relevant server(s) for the environment.

Hi Phil, This has to do with the Action Group that creates the Artifact. It's probably associated with (all deployables), which means it will be in the \0 folder. So, simply change the action group that creates or deployes the artifact to use the same deployable... either (all deployables) or DeployableX. Hope that helps... Steve

I could certainly try this if you can tell me how. Also would it be easy for me to unistall and go back to the previous functionality, if required? Please let me know what i need to do to test this.

I will also add that there is a feature in the pipeline named "Release Archiving", which will allow deployed releases to be archived and delete the artifacts from a release for all but deployed builds. It will also delete the execution logs and messages for non-deployed builds. This feature (at the moment) is not scheduled for any particular release, but it should be coming in one of the next few minor (3.X) releases.