With the new way of pushing packages and releases to Octopus in VSTS vNext, using the new Octopus task, it looks like each release can only go back in time to the previous build. So, if there are many releases for a "2.0" release, it seems all those work items would be sprinkled among all the dev/test builds and releases that had to happen to get to the "2.0" state. What i really want is the ability to accumulate work items since "1.0" so that all the new features and bug fixes that have happened for "2.0" show up on the Octopus release in one place.

I'd like to capture some additional fields along side every release.

For example, every release of my project, should have a corresponding:

• Team City Build Number
• Team City Build Type Id
• Team City Build Id

At the time of creating a release in Octopus, if done through the octopus UI - these values would be prompted for.

If done through Octo.exe then the create release command should have the ability to set these release specific property values.

The reason this is useful is because:

1. The Octopus Release number no longer has to match the Team City build number in order to tie the 2 up together. You could edit an existing release number, and would not break the link between the release and Team City, because the Team city build id for the release would be held in an additional property of the release.
2. Can store additional useful properties relating to the release such as paths to assets such as coverage reports etc.

At a releases level, i'd like to have the ability to define some custom fields (similar to the step template fields) that would be filled in whenever a release of the project is created.

that must be filled out for each release that is created.

I think this would also address this: https://github.com/OctopusDeploy/Issues/issues/1149#issuecomment-52598811

It would be great if Octopus would also support external NPM and Bower feeds instead of NuGet or the internal Octopus feed.

Background:
Octopus does a great job when deploying Windows software based on NuGet packages. As described in #2183 the NuGet package format isn't always suitable. Octopus now supports to store arbitrary archives in the internal Octopus feed. Although this might be useful in some cases, you don't want Octopus to become a package repository. Octopus can also fetch from TeamCity, but TeamCity is also limited to a NuGet only feed and should be responsible to build software, not to host it.

I think that neither TeamCity nor Octopus should be used as package repositories for large scale applications. There are numerous good alternatives (like MyGet or ProGet) that are specialized in hosting package repositories.

Octopus can connect to such a repository for NuGet packages, but this is rather limited. Creating NuGet packages on non-Windows platforms in cumbersome, but it's very easy to create a Bower or NPM package. If Octopus could fetch from NPM or Bower feeds, then these packages could be consumed in much more natural way.

Both package systems use a similar versioning scheme as NuGet and also supply meta information that is needed by Octopus for discovery of packages and their versions. Then you could use the following paradigm that uses proper separation of concerns:

• TeamCity: Builds software
• Octopus: Deploy software
• Proget: Store artifacts

It would be very helpful if you provided an octopus github app in the github marketplace as a way to auth when using github feed/github credentials.

Azure Devops and Terraform cloud currently provide this functionality and it is very helpful as it acts as an organisation service account rather than any 1 individuals account.

Currently if I create a PAT token for octo to use and then I leave the company that puts the other development teams in a bit of trouble, not to mention the security implication of any other user in octo being able to act as me.

While I know we could create another user in github specifically tailored for readonly access, call it devops, and use that, it seems a pretty ugly way of going about it.