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..

It's hard to say; 4.6 is quite old, so of course I recommend to upgrade so that it fixes any issues that might be there. But even in 4.6, the action just wrapped the commandline. So, t's about finding what and how the commandline is being used with the parameters you're specifying... You should be able to find the code on an old release here -- http://github.com/inedo/bmx-windowssdk

This is addressed in 4.7.6; was a regression.

ProGet does not support that versioning scheme. This was only recently added in Nuget v3.5; we may add it at some point, but we need to support older clients and need to keep the older rules for now.

As of ProGet 4.7.4, we are no longer performing any server-side filtering based on target framework. Can you confirm that you are on the latest version?

At this time, the NuGet team has no plans to make the v3 API publicly consumable, and will support the v2 API indefinitely as the public API; as such, we have no intention to reverse engineer and attempt to implement a private API. Note this it is entirely a "behind the scenes" transport mechanism (JSON vs XML) and makes no difference at all from a usage perspective.

That's a bug affecting NuGet feeds - we're publishing a hotfix release today (4.7.6) and will include a fix for this.

We test with the latest version of Posgres, but I haven't heard of any issues with 9.4 or newer. This ought to recreate the missing tables in your database: CREATE TABLE "Licenses" ( "License_Id" SERIAL NOT NULL, "External_Id" VARCHAR(50) NOT NULL, "Title_Text" VARCHAR(200) NOT NULL, CONSTRAINT "PK__Licenses" PRIMARY KEY ("License_Id"), CONSTRAINT "CK__Licenses__External_Id" CHECK (RTRIM(LTRIM("External_Id")) <> ''), CONSTRAINT "UQ__Licenses__External_Id" UNIQUE ("External_Id") ); CREATE TABLE "LicenseUrls" ( "License_Id" INT NOT NULL, "License_Url" VARCHAR(400) NOT NULL, CONSTRAINT "FK__LicenseUrls__Licenses" FOREIGN KEY ("License_Id") REFERENCES "Licenses" ("License_Id") ON DELETE CASCADE, CONSTRAINT "CK__LicenseUrls__License_Url" CHECK ("License_Url" NOT LIKE 'http://%' AND "License_Url" NOT LIKE 'https://%'), CONSTRAINT "UQ__LicenseUrls__License_Url" UNIQUE ("License_Url") ); CREATE INDEX "IX__LicenseUrls__License_Id" ON "LicenseUrls" ("License_Id"); CREATE TABLE "LicenseRules" ( "LicenseRule_Id" SERIAL NOT NULL, "Feed_Id" INT NULL, "License_Id" INT NOT NULL, "Allow_Indicator" YNINDICATOR NOT NULL, CONSTRAINT "PK__LicenseRules" PRIMARY KEY ("LicenseRule_Id"), CONSTRAINT "FK__LicenseRules__Feeds" FOREIGN KEY ("Feed_Id") REFERENCES "Feeds" ("Feed_Id") ON DELETE CASCADE, CONSTRAINT "FK__LicenseRules__Licenses" FOREIGN KEY ("License_Id") REFERENCES "Licenses" ("License_Id") ON DELETE CASCADE ); CREATE INDEX "IX__LicenseRules__Feed_Id" ON "LicenseRules" ("Feed_Id"); ALTER TABLE "Feeds" ADD "AllowUnknownLicenses_Indicator" YNINDICATOR NULL; DROP TABLE "FeedLicenseUrls" CASCADE;

ProGet does not currently implement the "_catalog" endpoint currently, which Octopus uses to detect the registry version. It's on our list, but we do not have an ETA for it now.