Closed ErisDS closed 5 years ago
@ErisDS Thanks for this PR. As mentioned on Slack, commit messages are significant for semantic-release
. There's more info in the CONTRIBUTING document.
As a suggestion, the first line of the commit message could be changed to:
feat(passenger): include snippets, servers & certs for passenger
The rest of the lines can stay as they are.
Option 4:
Any one using the old behaviour can get it back by changing nginx.passenger to nginx.passenger-pkg. New comers get the same behaviour regardless of if they include nginx or passenger.
Happy to work on any one of these options, if there is consensus as to the preferred approach.
@ErisDS I don't see a problem with the approach you took. With number 3:
Simple: just update passenger to work the same way as nginx (as in this PR)
Most people who used this as an add-on, will already have nginx configured in pillar. So duplicating the states won't do any harm.
:tada: This PR is included in version 2.3.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:
As it stands, including
nginx.passenger
doesn't do enough to result in a working install, unlikenginx
. In my usecase, we want to be able to swap betweennginx
andnginx.passenger
and have them be interchangeable with the same behaviour, bar the additional install & config behaviour for passenger.IMO, that could be structured in a few ways:
Including the state
nginx
withinstall_from_phusionpassenger: true
in your pillar installs passenger + does everything that the nginx state does - if you only include nginx.passenger, you only get the passenger install same as nowTreat the passenger state as an addon - so in top.sls you define:
Buuut in that case I think order is confusing and going to cause problems.
I'm using this on my fork.