314 results found
-
0 votes
-
API changes
Hi
In the previous version of Octopus (2.6) the 2 following properties were availabe:
LastModifiedOn
LastModifiedBy
it sounds like there has been a decision to suppress them as part of version 3.x.
As admin I find this auditing information very useful, and if anything I think that auditing should improve (it is very hard to track changes at the moment) - so I suggest to bring it back.
See more info:
http://help.octopusdeploy.com/discussions/questions/7091-api-change-from-26-to-3213-missing-information
Thanks
Nir1 vote -
When creating new release - option to update all step templates and deploy to target environment
It's very time consuming to test a change in step template.
To test a change, a user will need to:
- Navigate to a project that use the step template
- Update the deployment process
- Create a new release
- Cancel any failed deployment in the target environment
- Deploy the release to the target environment
I propose adding a few optional parameter in the create release page to stream line the process.
- Option to update all step templates
- Option to automatically deploy to a target environment (this will also cancel any failed deployment that's waiting for user action).
2 votes -
More complex filtering on machine Roles in step definitions
It would be really handy to say execute this step on all tentacles with the role 'FrontEnd' and 'Admin', or 'FrontEnd' but not 'OldOS'
As it is we are managing a whole bunch of roles and tags because some applications in a project can only be deployed to machines with a newer OS and some can only go to a Task server and some only to in internal server. NOT or AND would seriously simplify the 30 odd tags we have now :)4 votes -
New tab in deployment view: Parameters
At the moment, I have to dump the $octopusParameters to the output on the PreDeploy script.
It would be handy to have a new tab that lists all those parameters.
-- TeamCity has a similar concept where it lists
parameters
used for a build1 vote -
Allow configurable IP bindings for Octopus server
We are running multiple services, each with their own IP, on the same windows server and it would be extremely helpful if we could bind the Octopus server to a specific IP. As it is now it is not certain that it will use the IP we intended it to use, which might also affect the other services.
A simple IP choice in the binding interface would be great.
3 votes -
Allow a user to easily see how a OD2 variable resolves
If an OD setup uses a large number of Environment Variables, it can be difficult, and slow to use them for reference.
i.e. #{EnvironmentPath}-#{Suffix}-#{SecondSuffix} isn't particularly helpful, especially if
EnvironmentPath = #{ServerLocation}-#{ServerType}-#{TenantInstance}
And if it nests further, it becomes incredibly slow to see how it will resolve on a deployment, short of deploying.
If there was a way, during snapshots, or ideally through a "show resolved for : " button, then this would make it easier to reference urls from OD2.
1 vote -
Retention of NuGet Packages on the server for x releases.
If I want to delete a set history of NuGet packages like keep the last 20 packages on the server (Currently the only option I have is retention of number of days.) Is there a way to keep a clean-up of the NuGet based on the x number of historical packages that are needed for historical purposes?
4 votes -
multi-line input box for variables in step templates
When you create step template and set up variables, you can choose multi-line text box.
But you cant use default value with many rows because input row "Default value" is single-line6 votes -
Ability to select scopes (environment) as variable columns
This would make it possible to have distinct variables names in the vertical list showing its values side by side dependend on environment or target.
2 votes -
Server Version number on the diagnostics page
Octopus 2.6 used to put the current version of Octopus Server on the dashboard...I would quite like this back please!
1 vote -
Variable sets UI - add OR to scope filters
In variables sets editor – filters scope - to be able to OR environments or other scope filter parameters so that it is possible to list variables in a number of environments – this would help in comparing two environments to check variables are not missing.
2 votes -
Ability to give role/permission per environment/lifecycle phase
As a user I would like to be able to give to allow a user to deploy only on a certain set of environments or lifecycle phases
For instance any dev to dev, any QA to QA or Staging, and ops to prod
2 votes -
Project Status: Would love the ability to view the current state/status of my projects
Would love the ability to view the current state of my projects: At any given time either adding - or modifying projects we have many teams contribute to the overall project. Would be extremely beneficial to understand the current state of any given project : Ready for deployment - Work in Progress - Retired - Pending review - Open issues could be some of the :States" Could make them custom
2 votes -
Sub steps to inherit the environment settings from the first step
In the process definition for a project it would be really good if the sub steps under a step with sub steps could inherit the environment settings from the first step – at the moment you have to set the environments on each sub step.
1 vote -
UI: Make default size of powershell editor adapt to screen size
The powershell editor is great, but:
I know that there is a "full screen" button, but would it be nice, that the default editor adapts in width and height to the actual viewport?
or make it at least a little bigger, it loks ridicoulous small on my screen.
And there is another issue with the full screen size: the "insert variable" button is hidden (why?)...
3 votes -
Add conditional filter to Lifecycle Automatic Deployment
When using branching (and semver on each branch) to maintain feature and release branches, I have found that I do not want to auto deploy every build, rather, I want to only auto deploy specific types of branches automatically,
For instance, any build that comes from our master branch, should get auto deployed as far up the chain as possible, including production for continuous deployment. Or a hotfix branch should get auto deployed to a QA environment, while a feature branch should only be created and deployed manually.
If you exposed some powershell or other script with access to the…
5 votes -
Email Octopus Administrators if a Backup Fails
I'd like to see an option added to the Configuration -> Backup tab to send an email to users in the "Octopus Administrators" team if a backup fails.
1 vote -
Separate Project-level variable permissions from Variable Set-level variable permissions
I think project level variables and variable set level variables can be looked at in very different ways. Right now users only edit permissions based on whether a variable is scoped to an environment or not, but in addition to that, I can see a use case for allowing project variables to be edited, but not variable sets or vice versa. Conceptually these variables can be very different, and permissions should be handled independently.
2 votes -
Pinned packages
When we deploy branch packages as part of a patch, sometimes we are only deploying a few components of a project. The way we do this today is to create a new release, let octopus pick the latest version # for everything and then skip all components outside of the ones that we want to release.
The problem is twofold: 1) We may make a mistake when creating a subsequent release and accidentally forget to skip a component, and then that component would slip through even though we didn't mean to push it and most importantly - 2) This process…
2 votes