Any word on adding Proget Promotion functionality to BuildMaster

jstarbird_7831

I am unable to use Proget promotion from HTTP post, see other posting from me on that
http://inedo.com/support/questions/5569 , and I would really like to automate promoting a package.
I was told back in November that this was a coming feature in the Proget extension but have yet to see it added.
Will this be coming anytime soon? This would be very valuable considering it doesn't want to work via HTTP posts from BuildMaster.

Product: BuildMaster
Version: 5.6.11

We still plan to add this. It's taken a while because this required an SDK change to ProGet, specifically the ability to impersonate users via the API key (which is now available in 4.7). It hasn't been a high priority because of the Post-Http operation, which we're still not sure why it doesn't work for you. Here is an example that works for me:

Post-Http http://progetserver/api/promotions/promote
(
    FormData: %(
        key: full,
        packageName: HDARS,
        version: 1.2.3,
        fromFeed: universal1,
        toFeed: universal2,
        comments: Promoted by BuildMaster $ApplicationName $ReleaseNumber.$PackageNumber
    ),
    LogRequestData: true,
    LogResponseBody: true,
    UserName: windowsAccount,
    Password: windowsPassword
);

# note you can use $CredentialProperty(windowsAccountCreds, Password) instead of 
# windowsPassword if you create Username/Password credentials, at least until 
# Credentials are added as a property for this operation

In IIS, the only thing enabled is "Windows Authentication", every other type is disabled.

As I put in the other post, I did get it to work but only if I enabled Anonymous Authentication which then breaks single sign-on.
So I can enable that but I'd prefer not to if there is a way to work around it.

Meant to add, I do pass in credentials that are valid. I can use the same creds to login manually and promote a package.
As a matter of fact for the anonymous access I set it to that same account and then it works, it's only with that off that the creds don't seem to work.

"Anonymous Authentication" should definitely be disabled.

The main problem that was somehow missed previously was the lack of Username and Password properties for the operation itself. Those are required to ensure you don't get a 401 from IIS. In the example you submitted, you have "user" as part of the FormData instead of "Username" as an operation property.

I had that at one time but had removed it and went back to having it within the data.
I changed it back and now it seems to be validating ok but now I'm getting an odd error.
It's trying to Promote the Symbols version which makes some sense however the server doesn't have the Symbols version of the file in the feeds folder.

I'm not sure how that's possible... what is the error?

I should clarify as well, this package was uploaded as a Symbols version but in the folder on the Proget server it doesn't have a package by that name.

As to logs, on the ProGet server it shows nothing, just the valid Promote call in the API logs and in BuildMaster it doesn't give much in the deployment log.
File does not exist (Sci.Framework.Shared.Sm.Core.42.0.0.symbols.nupkg).

This Feed is setup to strip out the symbols, could that be causing this issue? I mean it's still a bug it seems but just wondering.

Also, I had upgraded to 4.7.11 prior to this attempt.

How was that package uploaded? The NuGet API or drop path should both remove the .Symbols portion of the filename. The only other thing that would affect the file name is the NuGetFeedCleanupTask in scheduled tasks, which removes the .Symbols portion of the name as well.

The only way then I could see this happening is if the file is placed directly on disk of the underlying package store with the .Symbols part of the filename still intact. Is that the case?

I upload it via Publish Nuget Package in BuildMaster. I use the Create Nuget Package in BuildMaster to create it and it has the filename at that time with symbols in it.

The file was never copied manually at all so however it is on the disk on ProGet is how ProGet did it.
I looked and we don't have any NuGetFeedCleanupTasks in the Scheduled Task area, for any feed.
We do have a general FeedCleanup task but that's it. I did look at the logs the day and day after this package was uploaded and it doesn't show anything about changing the file name, not sure if it should but it didn't.

btw, I wanted to point out that the problem is not what the file is stored as on the file system of Proget but rather the file name stored by Proget.
The error I am getting is when I try to Promote a package and I am not putting a filename, just a package name and version.
So Proget itself thinks the File has .symbols in the name.

I found the issue. User error on my part.
This is a small plan that handles this and I had a Legacy plan doing something similar but not using the Promote API.
The pipeline was still pointing to that old plan and I just didn't notice the calls going to Proget.
Then I was working on the new plan so as far as I knew it wasn't using the filename but in the old plan it was.

Changed to the correct plan and the Promotion worked fine.

Sorry for wasting your time on this.