This should not impact your ProGet installation

I solved this by configuring the URL including port number in the Advanced Settings at "Web.BaseUrl"

Don't use that, use the Variables API instead.

Thank you!! It's finally working.

Hi, So I delved into the Proget Vor Security extension and found the URL below gets used with the key on the end and a reference to a header too. Tried it through PowerShell and it is blocked so I'll get it added to the white list and retry :) https://vorsecurity.com/92614235v2.0/report/{id} Thanks for your help /Matt

It seems like the problem is caused outside of ProGet. So, i would investigate Windows integrated Authentication (if you have it enabled, disable it as a test). Also look for other "random" IIS settings that may have inadvertently been changed. It's also possible to be networking equipment (bad router, switch, etc).

For re-use: https://github.com/rockpooldigital/bmx-testresultssummary Cheers again, Jamie

Your best bet would be to simply wrap the deployment plan that gets called in a "if $RestartServer". I agree about visibility of skipping, but it's not supported at this time.

If you call $PackageNumber with no arguments, then the curent one in context is returned. The arguments allow you to find a package number for another release in potentially another application.

The extension should be available now.

ProGet for Linux is already out; it's shiped as a docker container. We have a lot of users who install ProGet on server core, but please note it's an advanced OS and requires a lot of commandline use. So, it's a bit more difficult to install ProGet on this. A ProGet Node is either the Web or Indexing Service. The "Load Balanced Only" comes with just three nodes, so for this yo you would have two web nodes and then Service node. An enterprise installation will have 5+ nodes, which typically is multiple services nodes (at least two) and then the rest web nodes. With automatic failover, basically if one of the indexing services becomes inactive, then the other takes over indexing duties. Sure, as long as the web and indexing service can access the files using the regular File IO (i.e. it shows up as a drive in windows), then you can use the regular disk package store for this.

Well, so that's basicaly the idea of a deployable; you could have a web deployable and a database deployable. Of course, the same pipeline is used, but you use a for deployable xyz block to determine whether particular things execute. You could use this, in combination with pipeline targeting, to accomplish this. They would still follow same linear pipeline path, but some stages would only deploy one or the other. Otherwise, you can use multiple applications, and then the create- and deploy-package operations. Down the line, we will have multi-release projects that allow you to tie together multiple releases of multiple applications.

If this is happening, then the package is not being deleted from the package store on disk and is being re-added by the routine index reconcillation. The most likely cause for this is a misconfiguration (pointing to wrong file store), a file permissions error, or a back-up system restoring the package. When you delete a package, it should be deleted from the database and from the disk.

We'll add this, likely as a separate endpoint i.e. api/releases/create-from-template or something like that. It will appear as BM-2384 in the release notes (likely before it is actually documented on inedo.com).

The environment on a raft affects who can access it, but not which raft is accessed. Asset names with no RaftName::part always use the Default raft. There's a bug in the implementation of OtterScript in the current version of Otter that makes it unable to call templates from a non-Default raft. Running a plan from a non-Default raft is also slightly broken in that it brings up the wrong preselected plan, but selecting the correct plan afterwards works.

You can make an AfterPushPackageAdapter in a plugin. There's an example of an adapter on GitHub.

It looks like running a pipeline on a server role does not correctly set the $RoleName variable. I've filed this as BM-2381 and it is fixed for the next version of BuildMaster.

I have filed this as PG-757 and it is fixed for the next version.

These are two separate errors: 404 - the package you asked for was not found 401 - you are not authorized to ask for a package If you configure your feed for authentication, then you're going to need to authenticate to the feed before you can query. The query will not even be considered if you do not authenticate. However, even if you authenticate correctly, if the package is not there, you will receive a 404. They are unrelated messages.

It's working again now, there was an issue with one of our feed URL's. But I would expected an HTTP 404 error instead of an HTTP 500 error then..