Background information:
For reasons, we wanted to package the output of the same csproj into two different packages. To accomplish this, I added the following to the project that we wanted to package twice so that it would create a second package using a different nuspec file after creating the first package:
However, TeamCity would sometimes fail to find the original package as shown by the following warning:
Artifact “E:\BuildAgent\work\77fc2b3067c5f251\MessageQueueWorkers\SystemScheduler\obj\octopacked\SystemScheduler.69.0.0.nupkg” does not exist and will not be published to the server
TeamCity appears to process publishArtifacts messages asynchronously while the build process continues to run, and this causes a race condition in which the second OctoPack process can purge the obj\octopacked directory containing the first package before TeamCity manages to publish it.
Request:
Update the ##teamcity[publishArtifacts] build message in method CreateOctoPackPackage.CopyBuiltPackages (specifically CreateOctoPackPackage.cs line 607) to refer to the final output location (specified by task parameter OutDir) instead of the one in the intermediate obj\octopacked directory.
Priority:
Low; we can work around this by specifying the final output package locations in TeamCity via option Build Configuration Settings->General Settings->Artifact paths.
Thanks,
Michael Ness
Hi Michael,
Thanks for getting in touch, this certainly looks like it’s something we should fix even if it only crops up in unusual cases such as yours. I’ve created an issue over on Github here which you can track. Feel free to add a comment over there if you think my explanation doesn’t cover things, although any of our guys taking a look at it will follow the link back to this discussion.
We also accept pull requests on all our open source projects if you feel like getting your hands dirty, it looks like you’ve done a lot of the the hard work for us already.
Regards,
Mark
Mark,
Thanks for the quick response and for converting this into an issue! Two
things make me hesitate to handle this PR myself. First, I notice that
there’s a nearby call to CreateOctoPackPackage.CreateTaskItemFromPackage
that might also benefit from being updated to use the final path instead of
the intermediate path as the result appears to end up being one of the
outputs of the task, but since that seems like it has a much broader
possible set of use cases I’d rather have someone more familiar with the
use of that output evaluate whether or not it should be updated and can be
updated safely. Second, this seems like something that would need more
testing than just unit tests, and setting up a test environment seems like
it would require a fair bit of effort on my part whereas I expect the
OctopusDeploy team already has one set up for their use and would be able
to test much more easily. If I were to do it, I’d have to either set up a
new TeamCity install or tiptoe around our existing build process to make
sure I don’t screw it up. If we didn’t have a workaround, I might be more
inclined to test by hacking a fix into our build process until it was
released, but since we have a safe workaround I’m not going to do such a
thing. Let me know what your thoughts are on the possibility that the task
output should also be updated, and let me know if this repository has
automatically run integration tests that would make my concerns around
testing this extensively myself less of an issue.
Thanks,
-Mike
Hi Michael,
I think you might be right about the CreatedTaskItemFromPackage call. We don’t currently run our integration tests on PRs for OctoPack, although we do for some of our other open source apps, and I’d like to beef up the testing of the integration with TeamCity looking at it now, so feel free to leave it to us. Thanks again for the great bug report, it always makes our job much easier.
Mark