cfn-stack-name parameter is not working with rake

[starchx]

$ rake example-qa:status --cfn-stack-name=example-qa-6
invalid option: --cfn-stack-name=example-qa-6

$ rake example-qa:status[cfn-stack-name=example-qa-6]
Stack does not exist

$ bora status example-qa --cfn-stack-name "example-qa-6"
example-qa-6 - CREATE_COMPLETE

[herebebogans]

@ampedandwired

I think theres 2 issues here.

1. The rake tasks with args.extra in stack_tasks.rb never receive the splt arguments from the rake command line. Eg. bundle exec rake my-stack:empty['arg1=arg2'] args.extra is empty

From this reference

https://stackoverflow.com/questions/18660282/rake-task-w-splat-arguments

If for eg - the apply task was rewritten like this

 def define_apply_task
      within_namespace do
        desc "Creates (or updates) the '#{@stack.stack_name}' stack"
        task :apply, [:options] do |_, args|
          @stack.apply(extract_params_from_args(args.extras))
        end
      end
    end

and rake called from command line.

bundle exec rake my-stack:apply['options, arg1=arg2']

2. For @starchx issue with overriding the stack_name from Rake Tasks I don't think it can be done currently. The apply task never calls Bora.new with the override_config in the same way the CLI options do.

[ampedandwired]

There's a bit of history here. The rake tasks were actually the written first, and the command line only came in later. Since then I've been focusing on the cli and the Rake tasks have lagged behind. I was actually thinking of deprecating the Rake tasks, although it looks like you guys are using them, so will look at how to evolve them.

One approach is for the Rake tasks to invoke the Bora CLI programmatically, in a similar way to how the tests do it (stack_helper.BoraCli), simply passing through the args through. That way everything that's available through the cli would also be available through Rake. Taken to the extreme, there could be just a single rake task that did everything: rake bora[apply, mystack, --params, x=y, --cfn-stack-name, foo] for example.

But that seems like it's not adding much value, why not just provide a few helper methods and let people call Bora from their own rake tasks. That probably gives the most flexibility.

require 'bora'
task :mytask do
  Bora.run("apply mystack")
end

[starchx]

@ampedandwired Thanks. I don't really want to put any cfn-stack-name etc into rake file. Can you tell me how do I get rake bora[apply, mystack, --params, x=y, --cfn-stack-name, foo] format working? That seems like what I need - to show progress in real time in Bamboo with STDOUT.sync = true Sorry, I am not familiar with rake.

[ampedandwired]

Are you only using rake to work around the STDOUT.sync problem? If so I can add that to bora itself so you can use the command line. If you'd prefer to continue to use Rake, I can probably look at implementing a "catch-all" bora Rake task that lets you run anything.

[starchx]

@ampedandwired Yes. I am only using rake to work around the STDOUT.sync problem. Thanks!

[herebebogans]

@ampedandwired I've been invoking bora directly from ruby (cucumber tests and rake) for a while. A typical flow is .

STACK_NAME="#{APPLICATION}-#{ENVIRONMENT}-#{BUILD_NUMBER}"
require 'bora'
stack = Bora.new.stack STACK_NAME
stack.diff
stack.apply({}, true)

We use ERB to template a bora.yml based on environment variables from the build system (dotenv gem makes this a breeze for local dev vs pipeline parameters).

It would be great to have all the CLI options available to Bora.new

[ampedandwired]

Handling CLI params is the responsibility of the Cli class which sits as a "front end" on top of the Bora class. If you want to use the Bora cli programmatically, you can do this:

require 'bora/cli'
Bora::Cli.start ['status', 'mystack']