This may or may not be a good idea depending on how you think about it. If each package is totally independent and they do not share any prerequisites then there is no value in running PreDeploy.ps1 for each package before, but the way I see it I don't want any packages being deployed unless every package can run its PreDeploy.ps1 successfully.
This could also be achieved by using an ad-hoc powershell step.2 votes
Create a new type of step that when reached will bring up a new browser window navigated to that page. Our workflow is after the deploy finishes, we hit a set of pages and verify parts of the product are ok. It would be awesome to have Octopus automate launching that part. I would appreciate it if after the deploy was done, Octopus could bring up a given URL on my machine.1 vote
The deployment process run by octopus is run in the tentacle (or server) process and does not issue commands back to the front end. We currently have no plans to involve browser processes in the portal in the deployment process.
the recent 4.0 front-end rewrite now uses material design elements
It would be really nice if you could enter have the parameters under version control or some history of changes you make.26 votes
Thanks for the suggestion.
We currently keep track of snapshots of deployment processes and variable sets, and changes to them are exposed via the audit log, which I think addresses the scenario in this suggestion. And you could use the REST API to export the variable set/deployment process now too and commit that to your version control of choice.
Sometimes we need to do extra changes when deploying large features. Things like running an SQL script or importing a package to our CMS.
Having powershell scripts which can be applied to specific releases without making our versioning messy would be useful.12 votes
I think the best way to implement this would be to conditionally perform steps in your deploy.ps1. E.g., if you know that this release, you need to run ScriptA.sql, then you could define a variable in Octopus (RunScriptA=true) and check for it in your Deploy.ps1 before running it.
This way if it needs to be run again at some point you can just set the variable to true again, or remove it in a subsequent package.
OctoPack.Web - Specific actions for create/update website on IIS. Defines in Project the PostDeploy.ps file with common actions for web applications
OctoPack.WindowsService - Actions to create and configure Windows Services, including powershell scripts.
OctoPack.WindowsTask - Actions to create and configure Windows tasks, including powershell scripts.
And so on.6 votes
The goals of this request are not quite clear.
Ideally I would like to substitute the current TCP connectivity with an alternate relay (say via Service Bus) to connect the machines. If there was a pluggable mechanism - you could leave the implementation up to an enterprise (sorting out credentials, payments, network specifics etc).6 votes
The whole comms stack between tentacle and server have since been rewritten in Halibut.
In a multi-tenancy environment you may have a single physical server (Server01) with multiple client systems running on it.
Each of these client systems is accesses the physical server via a client specific dns entry which is used within each clients Octopus project.
Now have multiple logical references to the same physical server, which can cause problems with tentacle upgrades as Octopus tries to upgrade tentacles in parallel.
Provide a means of identifying server aliases within Octopus2 votes
I've been working on adding a step to my project which is essentially another site completely. I'm thinking that it'd be nice to eventually just hit a link on the step defined in Project A and have OD create a new project containing that step, all the variables, etc.5 votes
Users can clone project and remove what they dont need.
This would make it easier for other people to create OctoPack packages. Some of the feature that are in the OctoPack package could most likely be implemented in a way that they could be re-used in other packages.1 vote
When calling any of the SP2010 powershell cmdlets, the script immediately ends citing the usual .net4 error - "System.PlatformNotSupportedException"
- Selection of the .NET CLR to execute a step in
- Select a "SharePoint 2010 required" option and manage the process execution including Standard Out/Error redirection so that these scripts output to the Tentacle log.
User can invoke another version of powershell if required
Automated Tentacle installation is a great start. Now we need to be able to push Tentacle to a machine from the Octopus server. This would also simplify the configuration as it would already have the fingerprints needed.16 votes
Thanks for this suggestion.
Tentacle can be fully installed and configured via command line and we’ve done a lot to make that easy. To actually execute the scripts on the remote machine really depends on the environment, and I don’t think there’s anything we can add to Octopus that will work for any majority of scenarios. Even if we did execute it, we’d only be making it slightly easier to do than using PSExec/PS remoting/group policy/EC2 user data scripts for the same outcome. So for this reason I’m going to close the suggestion. Thanks!
When a user adds a package step or chooses a package version for a release, capture the <title> element so we can display it instead of the package ID. If the <title> isn't available immediately, capture it later when it is available.6 votes
When a dashboard filter is applied, it remains set until cleared.
Once I have filtered the dashboard, I might open multiple projects based on that filter. When I return the dashboard, I would like my previous filter to be retained so I do to re-filter to see the next project0 votes
Editing the dashboard filter sets updates the URL, when you click “Back” (as opposed to navigating to dashboard again) the same filters should still be applied
The deployment name is available as a variable under Octopus.Deployment.Name
- Don't see your idea?