Hi Trevor,
I'm just walking onto a vacation - so I'm out for a week, to cut a long
story short; (§10.4.3 The Art of Unix
Programming<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.103.2799&rep=rep1&type=pdf>,
Raymond, 2003)
*When to Use Environment Variables*
What both user and system environment variables have in common is that it
would be annoying to have to replicate the information they contain in a
large number of application run-control files, and extremely annoying to
have to change that information everywhere when your preference changes.
Typically, the user sets these variables in his or her shell session
startup file.
I interpret that to mean, in effect the correct things to control through
env variables are things which are too subtle to have their own features
(i'e TERM, PATH, etc, etc, etc) - *features* deserve to be implemented
fully, it just happened that Tom went ahead and implemented something in
keeping with past style; and more power to him, at least it is usable now!
Although I do think that it violates some abstract notion of the "right
way" to do things.
I'd ideally like to see a configuration variable both for role filter and
host filter, and have them be settable via command line flags (for which
there's already reference implementations from other features that you
could pick up and build on if you felt like contributing that)
One of the main points of the rewrite was to make Capistrano a better
citizen, as far as scriptability, and testability was concerned, and in my
experience environmental side effects don't make for happy software
developers.
I'd much rather set --role-filter=sth than export ROLEFILTER=sth, as it has
topics around documentation, being self-documenting, and applying the
principle of least surprise.
I'm glad to have Tom's contributions on Capistrano (and indeed, I think he
may even have overtaken me as the chap with the most lines of code in the
core!) and he's doing a really great job, but the env var thing flies a
little bit against what I wanted to have built, and what I preemptively
documented.
To refer shortly to your example, please see the following:
desc "Does a code update for all local servers."
task :deploy_local do
on roles(:all, except: :remote), in: :parallel do |host|
on roles(:all, except: -> { |h| h.properties.remote ||
h.properties.no_release), in: :parallel do |host|
# unless host.properties.remote || host.properties.no_release
deploy.update
# end
end
end
You'll have to take a look at the filter code, it's in the roles()
function, that you'll find in Capistrano itself. I'm not sure if I made it
flexible enough to take a lambda, or just a symbol that is used as a lamba,
I did write some shortcut syntax into it, but it escapes me now, as I so
seldom use it (as we didn't get around to the host and role filters stuff
in earnest yet.) There's an inclusive, and exclusive filter, but as I said,
their exact usage escapes me , but it works something like that.
Note here, also it goes through the roles() function, this is the
Capistrano glue between Rake and SSHKit, and it leads to obscure errors if
you forget it (something else we'd like to improve!)
I'll be offline for a week, hopefully tom can help you, if you can't get
these things working, pleae feel free to open a GH issue, as it should more
or less work as described.
I'd be really glad of a patch to support host and role filters through a
CLI api that doesn't rely on poisoning the env.
Lee Hambley
--
http://lee.hambley.name/
+49 (0) 170 298 5667
On 5 September 2013 20:29, trevor walton <[email protected]> wrote:
> I am attempting to refactor some capistrano tasks from v2.15.4 to v3.
>
> I'm a little unsure what to do regarding code that uses the HOSTFILTER and
> ROLEFILTER ENV vars.
>
> The release announcement (
> http://www.capistranorb.com/2013/06/01/release-announcement.html), claims
> that these are going away to be replaced by command line flags.
>
> However, some recent github commits seem to indicate otherwise.
>
> https://github.com/capistrano/capistrano/issues/446
>
> Given the recent changes, is this refactoring correct?
>
> https://gist.github.com/tdwalton/873b0d9f39369430a4b3
>
> Does Cap v3 simply reflect the HOSTFILTER env var in it's hosts collection?
>
> Or do I have to do some special handling of the env vars, in my task code,
> like before?
>
> I'm new to both Ruby and Capistrano, and am attempting to update an
> inherited release process, so please excuse any ignorance exhibited above.
>
> Thanks.
>
>
>
>
> --
> --
> * You received this message because you are subscribed to the Google
> Groups "Capistrano" group.
> * To post to this group, send email to [email protected]
> * To unsubscribe from this group, send email to
> [email protected] For more options, visit this
> group at http://groups.google.com/group/capistrano?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Capistrano" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
--
* You received this message because you are subscribed to the Google Groups
"Capistrano" group.
* To post to this group, send email to [email protected]
* To unsubscribe from this group, send email to
[email protected] For more options, visit this group at
http://groups.google.com/group/capistrano?hl=en
---
You received this message because you are subscribed to the Google Groups
"Capistrano" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
