New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bundle Octo.exe with Octoposh #183

Closed
Dalmirog opened this Issue May 25, 2016 · 16 comments

Comments

Projects
None yet
6 participants
@Dalmirog
Owner

Dalmirog commented May 25, 2016

See approach -> #183 (comment)

Edit:

This was introduced in 0.6.3. Here's how it works: Full walkthrough of the new feature here: https://github.com/Dalmirog/OctoPosh/wiki/Running-deployments-with-Octoposh

@Dalmirog Dalmirog added the New Cmdlet label May 25, 2016

@Dalmirog Dalmirog added this to the 0.5 milestone May 25, 2016

@mattcorr

This comment has been minimized.

mattcorr commented May 26, 2016

Can I ask why this is needed? does Octo.exe do stuff the REST API can't?

@beaudryj

This comment has been minimized.

beaudryj commented May 27, 2016

i don't really understand the point if you already have the DLLs included and the DLLs and Rest API already offer more than the .exe

@Dalmirog Dalmirog modified the milestones: 0.6, 0.5 Jun 13, 2016

@Dalmirog

This comment has been minimized.

Owner

Dalmirog commented Jun 18, 2016

The idea of Octoposh being a PS module for Octopus that doesn't give you a way to start a deployment makes me sad. With that idea in mind, the obvious thought was "Hey I should totally create cmdlets to create releases/deployments using the API" so I created #100.

As soon as I started planning those cmdlets in my head, I realized I was basically re-writing Octo.exe in Powershell, which doesn't make a lot of sense. The Octopus team has put a lot of effort into Octo.exe through the years, and there was no way I could write something better than them. To answer to your questions, there's nothing Octo.exe can do that the API can't. Basically cause Octo.exe is just a smart wrap around the API. A very smart wrap supported by an entire team of amazing devs :)

The 2nd idea that came to my mind was "Lets bundle Octo.exe with Octoposh". Of course, just bundling a fixed version of Octo.exe would force me to keep releasing new versions of Octoposh every time an important fix was submitted to Octo.exe, which is also a lot of trouble.

So the current plan is

  • Add a cmdlet that lets you download a specific version of Octo.exe or the latest one.
  • This cmdlet would also create a variable that would always point to the path where Octo.exe was doenloaded, so users could to & $env:OctoExe create-release
  • Add another cmdlet that allows you to check which versions of Octo.exe you have downloaded, and to which is this Octo.exe variable pointing to.

Would love to hear your thoughts about this.

@mattcorr

This comment has been minimized.

mattcorr commented Jun 18, 2016

At the moment I am using OctoPosh to replace my current common library that I had created last year. Your code has pretty much replaced all function except for one:

function Create-Deployment($EnvironmentId, $ProjectId, $ReleaseId) 
{
    $newDeployment = @{ EnvironmentId = $EnvironmentId
                        ProjectId = $ProjectId
                        ReleaseId = $ReleaseId
                      }
    $body = $newDeployment | ConvertTo-Json

    return Invoke-RestMethod -Method Post  -Uri "$($env:OctopusURL)/api/deployments" -Body $body -Headers @{"X-Octopus-ApiKey"=$env:OctopusAPIKey}
}

Obviously the above function has some assumptions like the Release is already created.. etc.

I don't know as much about the inner workings of Octopus binaries as you of course, but I am uncertain how calling the REST API would be considered re-writing Octo.exe? Its just another path to get to the same functionality deep down right?

I am a bit on the fence between PowerShell functions calling an executable or just calling REST APIs and dealing with the objects via PowerShell. Its up to you how "pure" you want to the scripting to be. My previous approach was pretty much 100% powershell scripts and only calling executable when there was no other options. I could be persuaded if calling the executable is a more viable option! :)

My thoughts at the moment anyway. Keep up the great work!

@Dalmirog

This comment has been minimized.

Owner

Dalmirog commented Jun 19, 2016

That functions definitely gets the job done, but like you very well mentioned @mattcorr , it relies on too many assumptions and offers very little flexibility.

Octo.exe does things like:

  • Check if the release exists, and if not it creates it.
  • Check if the environment exists before starting a deployment on it.
  • Check if you should be able to deploy to that environment.
  • Offers a way to decide which version of each package you want to use in the deployment.
  • plenty other things related to releases/deployments

At the same time, in the latest versions Octo.exe has gained support to Create Packages and Push them to repositories

All of these are features I'd like to introduce to Octoposh to make it the Go-to cmd line toolkit for Octopus. But like I said, they are already in Octo.exe and re-writing them in Powershell makes very little sense. I'd rather focus on coding things that are not in Octo.exe, like cmdlets to create/delete resources and Get cmdlets with good enough filters that return objects and not plain text (like octo) so you can play around with them chaining them with other commands.

@beaudryj

This comment has been minimized.

beaudryj commented Jun 19, 2016

Why do they keep building on the .exe when they could work with you to
build stronger web APIs and wrap the dlls?
On Sat, Jun 18, 2016 at 8:13 PM Dalmiro notifications@github.com wrote:

That functions definitely gets the job done, but like you very well
mentioned @mattcorr https://github.com/mattcorr , it relies on too many
assumptions and offers very little flexibility.

Octo.exe does things like:

  • Check if the release exists, and if not it creates it.
  • Check if the environment exists before starting a deployment on it.
  • Check if you should be able to deploy to that environment.
  • Offers a way to decide which version of each package you want to use
    in the deployment.
  • plenty other things related to releases/deployments

At the same time, in the latest versions Octo.exe has gained support to Create
Packages
http://docs.octopusdeploy.com/display/OD/Using+Octo.exe and Push
them to repositories

http://docs.octopusdeploy.com/display/OD/Pushing+packages

All of these are features I'd like to introduce to Octoposh to make it the Go-to
cmd line toolkit for Octopus. But like I said, they are already in
Octo.exe and re-writing them in Powershell makes very little sense. I'd
rather focus on coding things that are not in Octo.exe, like cmdlets to
create/delete resources and Get cmdlets with good enough filters that
return objects and not plain text (like octo) so you can play around with
them chaining them with other commands.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#183 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ACgvXBdFY0wgpZU7SbVYNuMPKaKrPwLoks5qNImwgaJpZM4InCg5
.

@matt-richardson

This comment has been minimized.

matt-richardson commented Jun 20, 2016

@beaudryj - all of Octopus is based on web api's. Everything octo.exe does is via the REST api.

@Dalmirog

This comment has been minimized.

Owner

Dalmirog commented Jun 22, 2016

Just like @matt-richardson said, the DLLs that Octo.exe uses simply call the REST api.

@beaudryj for the moment that's not in our plans. Octoposh is still a project I maintain in my free time. But who knows? Perhaps the module becomes amazingly popular one day and we might consider making it a bit more official :)

@mud5150

This comment has been minimized.

mud5150 commented Oct 18, 2016

Why not use chocolatey or nuget to pull down the dependencies? This would cover updating the octo client library and the octo.exe.

@Dalmirog

This comment has been minimized.

Owner

Dalmirog commented Mar 26, 2017

Hi @mud5150 . I'm currently working on a prototype that downloads Octo.exe using Nuget or Chocolatey (still haven't decided whcih I'm gonna use). I'm planning on shipping the first version with 0.6.2/1.0.0-Beta2

@Dalmirog Dalmirog modified the milestones: 0.6.2/1.0.2-Beta, 0.6 Mar 26, 2017

@beaudryj

This comment has been minimized.

beaudryj commented Mar 26, 2017

@Dalmirog

This comment has been minimized.

Owner

Dalmirog commented Mar 27, 2017

Hi @beaudryj I'm currently working in a model that goes a bit like this:

The entire point of the cmdlets and variables below is for the user to have a simple and stress-free way to execute Octo.exe regardless of where their prompt is on.

Octoposh would introduce 2 new environment variables and a couple new cmdlets:

  • $Env:OctopusToolsFolder. This variable will point to a folder that has child folders with versions of Octo.exe

  • $env:Octoexe. This var will point to the current default Octo.exe version. The goal is that you can do & $env:Octoexe create-release -bla -bla from anywhere in your prompt.

  • Set-OctopusToolsFolder. Will set the value of $env:OctopusToolsFolder

  • Get-OctopusToolsFolder. Will get the value of $env:OctopusToolsFolder

  • Set-OctopusToolPath. Will set the value of $env:Octoexe

  • Get-OctopusToolPath. Will get the value of $env:Octoexe

  • Install-OctopusTool. Will download a given version of Octo.exe from Nuget/Chocolatey (still haven decided) to the path in $env:OctopusToolsFolder

  • UnInstall-OctopusTool. Will help cleaning up unnecesary versios of Octo.exe lying around in $env:OctopusToolsFolder. It'll have a parameter called -keepLatest so you can just keep the most recent version of Octo.exe

Would love to hear some thoughts on this.

Edit + disclaimer: I know that having a cmdlet just to get/set environment variables may sound like too much. But this sort of hand holding is a bit of a standard in Powershell and tbh I don't mind adding them. Its the same story with Set-OctopusConnectionInfo,$env:OctopusAPIKey and $env:OctopusURL

It also makes the overall usage discovery a lot simpler rather than forcing users to know about these environment variables before hand and making them set them on their own. Yo can still be a haxxor and set them manually without the get/set cmdlets if you want.

@beaudryj

This comment has been minimized.

beaudryj commented Mar 27, 2017

Cool Stuff, do you plan on creating commandlets that invoke-octo.exe and pass parameters? if so how do you plan on handling the output for errors ?

@Dalmirog

This comment has been minimized.

Owner

Dalmirog commented Mar 28, 2017

@beaudryj actually it wan't in my plans to do that that. All the module will do is:

  1. Make it easier for the user to download Octo.exe
  2. Point $env:Octoexe to the path of an Octo.exe copy, so you can easily invoke it like this:
& $env:OctoExe create-release --server http://server.com --apikey API-1234567 --Project MyProject

Creating cmdlets to wrap around Octo.exe would introduce a bit of unnecessary overhead IMO. If the Octopus team adds a parameter or a new command, Octoposh users would have to wait until a new release is out that supports these changes in Octo.exe. With the approach I'm proposing all they'll have to do is run Install-OctopusTool -Latest -SetAsDefault and they'll get the latest version from Nuget ready to go.

I guess I could add something like:

Invoke-OctoExe -parameters "create-release --server http://server.com --apikey API-1234567 --Project MyProject"

It wouldn't do anything more than invoking Octo.exe using the string passed to -parameters as parameters, but it would at least improve the discovery of the feature:

New user downloads Octoposh -> Runs get-commands -module Octoposh -> Notices a cmdlet called invoke-Octoexe and says "Oh there's a cmdlet for that!" -> Tries to run it without having ran Install-OctopusTool in the first place -> Gets a nice error that tells him what to do and points to documentation on how to get started.

How does that sound?

@Dalmirog Dalmirog self-assigned this Mar 28, 2017

@Dalmirog Dalmirog changed the title from Bundle Octo.exe with the module to Bundle Octo.exe with Octoposh Mar 28, 2017

@dragon788

This comment has been minimized.

dragon788 commented Mar 31, 2017

I'm liking where you are going with this. I'm partial to Chocolatey as the Octo.exe distribution method (just love the easy package management and ability to create your own if the gallery doesn't meet your needs), and at one point they were syncing some of the Nuget gallery over as a service to their users, not sure if that is still happening or if a change on the Nuget side broke something. I'm guessing eventually OneGet will work with Nuget or Chocolatey so for Windows 10 (or PowerShell 5.x) and up it will be much easier to install packages no matter the source.

@Dalmirog

This comment has been minimized.

Owner

Dalmirog commented Apr 1, 2017

@dragon788 I ended up going with Nuget.org and using the Nuget api to download Octo.exe like this: http://blog.nuget.org/20130520/Play-with-packages.html

It should be fairly transparent to the user that way :)

Full walkthrough of the new feature here: http://octoposh.readthedocs.io/en/latest/advancedexamples/running-deployments-with-octoposh/

@Dalmirog Dalmirog closed this Apr 1, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment