522 results found
-
Allow a user to select which team they are operating under after login
The same user may be assigned to different teams, and would like to have the set of projects and environments that are displayed on the dashboard to be filtered by which team the user is currently acting as a member of. For example, user Bill is a member of the Sustaining Team and also the New Development team. He would like to log in and then choose the Sustaining team as the team he is operating under for that login session, so that he then only sees projects and environments that are relevant to Sustaining Team members.
1 vote -
Pass environment parameter list of sensitive variables
Pass an environment variable to deployment PS scripts that lists the names of sensitive variables. We would like to mask these in our file logs and currently only have the choice to output NO variables or worse, log the sensitive variable values.
1 vote -
date based retention policies
we are constantly switching branches that we install to our different environments. Noticed the disk are running full and realized it is because packages from old branhces are never automatically removed with current retention policies.
Teamcity has the feature of cleaning out "More than X days older than the last 'build'" and "Older than the X-th successful 'build'"
As I'm writing this I realize it might be quite hard to figure out if a deployment is still in use.. maybe if no current octopus project maps against the packages installed on the tentacle, it can remove the packages/applications from the…
1 vote -
Apply desired state to environments
On the environments page, enable desired state configurations to be created and applied to roles. The desired state could be achieved using script templates (similar to deploy process). The desired state could be applied on a schedule or on drift.
There would need to be a way of updating the desired state configuration when something is modified in the deploy process ie. adding a new web site.
1 vote -
Display package versions in addition to project release versions on the dashboard
In addition to displaying the project release version on the dashboard, it would be nice to see the associated package versions as well.
e.g.
Dashboard
Dev
myServices 1.0.1 (myWebservice1.0.2 + myWindowsservice1.0.3)At present, if you want to find out what package version is associated to a project release you need to drill into the project.
1 vote -
Lock variables during editing
Not too often, but occasionally we have to update a project or variable library with a lot of changes. It would be great if there was a way to lock the variable set so after someone spends 30 minuets updating the variables they don't get a message stating that they can't save because another user made a change during this time.
1 vote -
Give API access to the system variables inside of Octopus deploy.
I've been looking through the REST Api,
GET /api/variables/names HTTP/1.1
Seems to show you the names of the variables in use. But there is no existing way to get a definition of what these are through the REST API. This would be highly useful for automated testing.
Some of these system variables are also used inside of the deployment variables. It would be nice to be able to have access to the system variables, in order to resolve the environment variables.
This way a tester could read from Octopus deploy REST API, and execute specified tests.
1 vote -
Associate variables to environments
I'd like to be able to 'tag' an environment with one or more variables and then be able to use these variables in my release process.
My specific use case is that I'm deploying to Azure and want to set the slot based on the environment being deployed to (Production or Staging). This works nicely with the use of #{Octopus.Environment.Name} if my environments are specifically named "Production" and "Staging", but I'd like to be able scope my environments to project groups and this requires them to have unique names. So I name my environments something like "<project>-Production" and "<project>-Staging", unfortunately…
1 vote -
Pack and Go
Add an option to create a deployment package just like a zip file with parametrizable powershel script file and all packages as a single setup step for non-octopus driven deployment from the deployment steps.
1 vote -
Allow option to set or override variable values from within a Manual Intervention step
While we make great of environments and machine roles for our production servers and devices, we still find it difficult to manage certain test scenarios without having to maintain a very large collection of test environments in order to mimic each distinct production environment. It would be nice to have an option, at the deploy time, to override or set certain variables, allowing a single test environment that can be dynamically configured to use various settings.
1 vote -
Decorate overridden config file settings with an Octopus tag (or something)
Some of our services have large config files and we will allow some settings to be defaulted (not configured through the Octopus UI) and others must be configured. I would like a Project Level setting to be included that if enabled would decorate the deployed config file with some indication that Octopus overrode the setting. This would help tremendously to be sure which settings were defaulted and which were set by Octopus.
1 vote -
Add ability to specify a minimum powershell version for a step template
Step template should not run if minimum power shell version is not met.
1 vote -
Deploy without storing a package or release
I want to use Octopus to deploy an application without having to store a nuget package or create a release for it. The reason for this is that some of my automated tests are end to end tests that I run against a deployment in my WiP environment. If these tests fail, I don't ever want to be able to deploy that version of the application. The best was I see to do this is to be able to directly deploy a package through Octodeploy. Once these pass I could potentially create a release from what I just pushed or…
1 vote -
Enable one to be able to iterate a list of last installed directory paths for steps in project
Create an Octopus variable that contains the last installed directory paths for the steps in the project. This becomes useful if you have one step that deploys and another that works on the previously deployed step, but for some reason you deployed one set of steps first and later the remaining steps.
1 vote -
Configure Default Deploy Options
It would be nice if you were able to configure defaults for deploy options. Currently they are all false by default. I never really had a need to check any on a regular basis until Guided Deployments are introduced but now I find myself checking this option with every deployment, which isn't optimal. I'm not sure if it would be best to be able to configure these on a per project level or perhaps project group level but it would be nice to configure their defaults somehow.
1 vote -
Scope variable to Package/Step
We have a project existing out of 60 packages.
In every package the in a appsetting in the config file.
We now need to have in 1 specific package another value for the appsetting.
Now we need to create a new appsetting in the config file and do some coding to read another appsetting for that 1 specific package.
If it would be possible to scope a variable to a spefic step/package would be nice.0 votes -
Add channel to the deploy release page
On the deploy release page (the one that shows just before actually deploying a release) the channel (if any) is not shown anywhere on the page. Would be very useful to avoid mistakes when deploying.
0 votes -
Deploy in "Debug Mode", pause after each step
It would be useful to be able to run a deployment in "Debug Mode", where it would execute one step at a time, pausing after each step, so a developer can verify that it is operating correctly.
0 votes -
If a step failed on a specific Target / Tentacle remove it from the list of targets for future steps
It would be configurable and we could leverage the existing functionality of how the Health Check steps take targets out of the list for future steps.
0 votes -
Provide access to account credentials during deployments
When a deployment is being executed, there may be some value in providing access to account credentials that have already been stored and managed in Octopus Deploy.
While the primary motivating factor for creating the accounts section has been to provide access to deployment targets, some users may get value from using them to access or control other parts of their deployment process that sit behind some authentication mechanism. This would allow OD to better manage all the resources needed to fully complete a deployment with authentication details being securely managed in one place.
The biggest concern with this approach…
0 votes