Skip to content
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

Support Templates deferring package selection #4270

Closed
zentron opened this issue Feb 12, 2018 · 13 comments

Comments

@zentron
Copy link

@zentron zentron commented Feb 12, 2018

Problem

Currently when creating a step template that uses a package, we require the user to define the feed and package directly in the step. The consuming project will then just use whatever package was defined down in the template. This approach has several limitations when users want to provide custom packages for different projects.

  • The user is required to use variables to define the package. This is unwieldy, and brittle (and just not aesthetically pleasing 😄 )
  • Using variables means that retention policies can no longer clean up their packages, causing space issues that need to be manually managed by the user outside of Octopus.
  • Auto release creation can no longer trigger since it has no deterministic way to work out if a given package is relevant or not.

A highly voted UV suggestion Automatic release creation to allow packages with variables in IDs (192 votes, in the top 15) describes the side-effects of this problem.

It feels as though much of the root cause of other trending issues such as

may also be partly mitigated if users had less need to use variables for packages.

A New Hope

A potential solution for this may to be to provide a flag to optionally source the package in a step template from the consuming project (or consuming step template in the case of Composite Templates 😉 )
image

When this step is included in a project, then alongside the parameter that the user can provide, is the package selector. From that point on from Octopus point of view the selected package can be treated like any other package step.

Ultimately in Octopus, packages are at the core of most deployments and so we should ensure using them are treated in as first-class a way as possible.

@ccamburn

This comment has been minimized.

Copy link

@ccamburn ccamburn commented Feb 12, 2018

I cannot +1 this enough. This is a large reason we cannot use many step templates. A prime example is IIS; we always deploy our sites in a similar manner, but they use different packages. If we use a template, our deployment process has #{variable_name} all over, and the retention policy breaks.

@blakeduffey

This comment has been minimized.

Copy link

@blakeduffey blakeduffey commented Feb 12, 2018

Please add me to this list. It would be very nice to have a cookie cutter Deploy to IIS template where I could specify the package later.

@TCGDrew

This comment has been minimized.

Copy link

@TCGDrew TCGDrew commented Aug 23, 2018

+1 x a billion!

@mildsar

This comment has been minimized.

Copy link

@mildsar mildsar commented Sep 4, 2018

When will it be implemented?

@Flamage82

This comment has been minimized.

Copy link

@Flamage82 Flamage82 commented Sep 5, 2018

@mildsar This is definitely something we'd like to work on sooner rather than later, and the number of votes in UserVoice clearly shows that our community really cares about this problem. We think we'll need to address #4390 first before we can tackle this item, so unfortunately we can't give any sort of timeline at this stage.

@ccamburn

This comment has been minimized.

Copy link

@ccamburn ccamburn commented Oct 9, 2018

Another use case, now that Octopus supports multiple packages when running scripts:

We often have a "Scripts" package, that contains all scripts used for deployment of all applications, and a "Client" package, that contains custom client sql scripts. We would love to have a single step that executes a script from the Scripts package and references custom-client code in the Client package, but we use Step Templates for most things. This means we cannot use the built-in retention policies if we move to this new model. For now, we have to deploy the client package to the server, then execute the code, then delete the client package.

This would definitely make life easier by having a single step contain all components.

@jess-ross

This comment has been minimized.

Copy link

@jess-ross jess-ross commented Oct 24, 2018

For your feedback, we've put together a couple of prototypes of how this could work.

One thing to note is the we'd like to introduce a new pattern to the SelectWithAddRefresh component. Rather than going to a new browser tab to create a parameter this would happen in place via a dialog. This way the user is kept in the context of the step tab. Alternatively the user can create the Package Parameter on the Parameter tab and select it from the drop down selector on the Step tab.

**When viewing the prototypes, if you click on the screen an orange highlight will show you where to click to move through the prototype

Deploy package step template : https://sketch.cloud/s/egpWq/LvVJLL/play

Script step template with reference packages : https://sketch.cloud/s/egpWq/g83rlM/play

@ccamburn

This comment has been minimized.

Copy link

@ccamburn ccamburn commented Oct 25, 2018

@jess-ross Looks perfect. I especially like that on the Step Template it specifically provides the option to "Source package from project." That makes it clear and distinct from a normal parameter.

In that scenario, in adding the step template to a project, I would like to request still receiving the appropriate auto-fill and dropdown to select packages from the internal feed, just like when adding the "Deploy a package" step. This way I don't have to type out the entire package name.

@zentron

This comment has been minimized.

Copy link
Author

@zentron zentron commented Oct 25, 2018

@ccamburn yep that should be the expected behaviour on the project end. When adding the template as a step, where you usually see text boxes for each parameter, you would see a full "package selection" section, with feed\package\acquisition options. That's the plans at least ;)

@droyad

This comment has been minimized.

Copy link
Contributor

@droyad droyad commented Feb 6, 2019

I don't agree on the point re package retention. In almost all cases the variables are applied successfully and the packages cleaned up.

@zentron

This comment has been minimized.

Copy link
Author

@zentron zentron commented Feb 20, 2019

This still feels like a high valued change to me. Will re-investigate in the future

@ccamburn

This comment has been minimized.

Copy link

@ccamburn ccamburn commented Feb 21, 2019

@zentron Great to hear. Been excited ever since the mockup.

@hnrkndrssn

This comment has been minimized.

Copy link

@hnrkndrssn hnrkndrssn commented Oct 8, 2019

Release notes: Allow deferring the package selection until the step template is added to a project

@hnrkndrssn hnrkndrssn self-assigned this Oct 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
10 participants
You can’t perform that action at this time.