ingenieux/beanstalker

update-environment now requires cnamePrefix

Closed this issue · 10 comments

I recently updated my project to the latest version (0.2.9) of beanstalk-maven-plugin and now it seems that the environmentName configuration setting is no longer being used by calls to update-environment. Instead it looks like it is using cnamePrefix to lookup the environment. I had not previously set a cnamePrefix and it was incorrectly guessing one using the maven project name.

Unfortunately, in my beanstalk setup I do not use cname prefixes at all, and manage naming via Route 53. So my cname prefixes are auto-generated by AWS. I also occasionally terminate/recreate environments which results in a new cname prefix. What is always consistent is the environment name.

Any chance on getting the old behavior back?

Could you pastebin me a pom.xml snippet? At first sight it seems a
lookup-cname-prefix mojo to do the trick. I opted for cnamr prefix in order
to make things simpler - there are dozens of deployment strategies out there
On Mar 13, 2013 4:29 PM, "George Scott" notifications@github.com wrote:

I recently updated my project to the latest version (0.2.9) of
beanstalk-maven-plugin and now it seems that the environmentNameconfiguration setting is no longer being used by calls to
update-environment. Instead it looks like it is using cnamePrefix to
lookup the environment. I had not previously set a cnamePrefix and it was
incorrectly guessing one using the maven project name.

Unfortunately, in my beanstalk setup I do not use cname prefixes at all,
and manage naming via Route 53. So my cname prefixes are auto-generated by
AWS. I also occasionally terminate/recreate environments which results in a
new cname prefix. What is always consistent is the environment name.

Any chance on getting the old behavior back?


Reply to this email directly or view it on GitHubhttps://github.com//issues/27
.

I created an example gist (https://gist.github.com/gscottrw/5157068). The example no longer works for me as is, you have to uncomment the camePrefix line for it to work. The output of maven looks something like this when there is no cnamePrefix element:

[INFO] Looking up for my-project.elasticbeanstalk.com
[WARNING] FAILURE
java.lang.RuntimeException: org.apache.maven.plugin.MojoExecutionException: No environments found

Where my-project is my pom's artifactId. So the mojo seems to be performing a lookup by cnamePrefix, rather than a lookup by environmentName as it used to do. I think I was previously on version 0.2.5 of the plugin.

We disabled in 0.2.7-RC6:

https://groups.google.com/d/msg/beanstalker-users/a-Cq-mHhCHk/8LyHTl8p5fkJ

However, I'm adding an exception for environmentName. Default must be ${artifactId-env}, but you can always override from the CLI (it used to be "default", but AWS does not recommend this nomenclature).

Meanwhile, the 1.0-SNAPSHOT is adding back environmentName. Once github publishes the commit, you shall be safe to use it from the Sonatype OSS Snapshots add https://oss.sonatype.org/content/repositories/snapshots into your <pluginRepository/> section and bump version to 1.0-SNAPSHOT

Great, thanks for the fix!

Confirm it's working please
On Mar 13, 2013 8:35 PM, "George Scott" notifications@github.com wrote:

Great, thanks for the fix!


Reply to this email directly or view it on GitHubhttps://github.com//issues/27#issuecomment-14875554
.

Just tried and it works for me with current 1.0-SNAPSHOT. thx.

Great!
On Mar 13, 2013 9:04 PM, "George Scott" notifications@github.com wrote:

Just tried and it works for me with current 1.0-SNAPSHOT. thx.


Reply to this email directly or view it on GitHubhttps://github.com//issues/27#issuecomment-14876644
.

Shameless plug: Consider donating to support development. I just took three
wisdom teeth just before evaluating your inquiry.This let's you know how
much we are committed to it :)

http://beanstalker.ingenieux.com.br/donate.html
On Mar 13, 2013 9:09 PM, "Aldrin Leal" aldrin@leal.eng.br wrote:

Great!
On Mar 13, 2013 9:04 PM, "George Scott" notifications@github.com wrote:

Just tried and it works for me with current 1.0-SNAPSHOT. thx.


Reply to this email directly or view it on GitHubhttps://github.com//issues/27#issuecomment-14876644
.

and btw, see if fast-deploy isn't any better. For scenarios like yours, all you need is something like this example:

https://gist.github.com/aldrinleal/5158439

As is stands, it will take care of almost everything.

1.0 was released