Thanks Phillipe, we've identified the bug and will fix it in next maintence release as [OTTER-133]

Yes, that is what I'm looking for. Sorry I didn't say it that way but I didn't think that was possible based on the docs, I thought having the sub-types like that was only in the maps. I tried that out and it works perfectly for me. Thanks!

Please see Cloud Package Stores for more information on how to configure these.

The url is wrong, and we will update this in the next maintence release

Hi Jason, there's not currently... but I've added a request to get this in a maintence release under BM-2374 @ConfigurationFiles([AppName]) @ConfigurationFileInstances(configurationFileName, [AppName])

We tried to reproduce this, but I get this output, which doesn't include "arguments" and which doesn't put a trailing slash after the destination directory: INFO : 2017-02-22 17:50:04Z - Executing SVN export... DEBUG: 2017-02-22 17:50:04Z - Using TcpAgent agent on GODZILLA DEBUG: 2017-02-22 17:50:04Z - Working directory: DEBUG: 2017-02-22 17:50:04Z - Executing: C:\ProgramData\InedoAgent\BuildMaster\ExtensionsTemp\Subversion\Resources\svn.exe export "https://github.com/Inedo/bmx-subversion/trunk/" "C:\ProgramData\InedoAgent\BuildMaster\Temp\_E78\_D0" --non-interactive --trust-server-cert DEBUG: 2017-02-22 17:50:12Z - A C:\ProgramData\InedoAgent\BuildMaster\Temp\_E78\_D0 [snip] DEBUG: 2017-02-22 17:50:12Z - A C:\ProgramData\InedoAgent\BuildMaster\Temp\_E78\_D0\packages.config DEBUG: 2017-02-22 17:50:12Z - Exported revision 63. INFO : 2017-02-22 17:50:12Z - SVN export executed. Caan you submit the plan and logs in a ticket? Tjhis will be much easier for us to research.

Yeah, I have the same problem, if I change TargetFramework from net45 to net452 they show up.

That is exactly what I was looking for. Thank you.

I see. It appears that dist-tag rm is now failing. We'll investigate and if we are able to reproduce this then it should be easy enough to get in the next maintenance release.

I found the issue, just didn't think about looking at the IIS settings but that clued me in. I needed to use Windows authentication via Powershell. For those that might hit this in the future this is the piece of code that did the trick: $pwd = ConvertTo-SecureString $userPwd -AsPlainText -Force $creds = New-Object System.Management.Automation.PSCredential($userName,$pwd) $Response = Invoke-WebRequest -URI $URL -Credential $creds

Thanks Dean, upgrading to 4.7.3 has solved the issue!

thanks, yes I saw that and that is what I am using. I guess the expectation I had was to see the description or synopsis in the dialog when I am adding it a plan. Once it's in the plan is useful, the way it displays now, but it's when it's being added that the person adding it needs the info. I'll just submit a feature request, it's not a major thing just be nice for people who use them later and may not know exactly what they do without opening the full script itself or reading some other doc outside BM

Release template values are currently only used by the user interface, as a means of assisting users enter key/value pairs (variables) for a release or package. They API does not reference these, but you can pass variables into the APi quite easily.

Thanks for the clarification; I was able to repro this and logged a bug report (BM-2371). It will be addressed in a future maintence release.

Hello Alana, Thank you for reply. Adding "Delete Files" step before "Get Git Source" worked for me. Deleted files don't appear in newly created artifacts anymore. cheers, Milan

By default, all you need is the name. The following operations are equivalent: Deploy-Artifact my-artifact-name; # and... Deploy-Artifact my-artifact-name ( To: $WorkingDirectory, Application: $ApplicationName, Release: $ReleaseNumber, Package: $PackageNumber, Deployable: $DeployableName, DeployAsZipFile: false, TransferAll: false, DoNotClearTarget: false, Verbose: false ); This should be mentioned in the auto-generated docs but since it is not, I'll put in a note to do that :)

I tried to use the docker API, however I'm having problems accessing it For example, according to the API documentation: GET /v2/<name>/manifests/<reference> Should get the signature, however using this call: curl -H "Accept: application/vnd.docker.distribution.manifest.v2+json" -X GET -vvv -k https://<host>/<repository>/v2/<image>/manifests/latest Returns not found. What is the correct way to call v2 API from a proget docker repository ? I couldn't find any documentation about it. Thanks Francisco

Figured it out. It's not the user running the installation that needs db_owner membership. It's the SQL user (i.e. progetuser) created in the original setup that needs temporary db_owner membership for the upgrade process. Thanks.

Thanks for the bug report. This will be fixed in v4.7.2, which should be released today. To upgrade, see the "Upgrading to a new version" section of this KB article: http://inedo.com/support/kb/1100/getting-started-with-proget-for-linux Basically though, when the container starts up it makes sure the database schema version is current, so all you really need to do is run the new container and point to the same data.

Yes that is a bug then. I'll submit a bug report.