-
Notifications
You must be signed in to change notification settings - Fork 20
Conversation
@@ -20,7 +20,7 @@ object BuildSettings { | |||
// Common settings for all our projects | |||
lazy val commonSettings = Seq[Setting[_]]( | |||
organization := "com.snowplowanalytics", | |||
version := "0.6.0-M1", | |||
version := "0.6.0-RC1", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should be "rc" lower-case
Very minor tweaks - please make those and then I will get the rc1 into acceptance testing. I'll also ask @fblundun to do full code review - Fred please go for it! Also please link in the branch with the blog post when it's ready... |
@alexanderdean typos has been fixed. |
Solution: ticket to remove aws-tools from the vagrant.up |
@alexanderdean can we fix a playbook? Or do you think it shouldn't even belong here? |
Actually, yes, removing it makes sense. We need to run fatjar from a machine with keys and credentials anyway. |
Yep, the one in question uses the long-deprecated EMR CLI: https://github.com/snowplow/ansible-playbooks/blob/master/aws-tools.yml#L6 So even if we need to replace it with something else in the future, I think we should remove it... |
2e2238e
to
437a6d1
Compare
When I attempt
|
Weird. I had similar errors when I compiled it on local machine and after that tried to recompile in vagrant VM without cleaning target dir. |
I'll try cleaning the target dir |
Also, is it possible that you have some files from old version not modified? It tries to find |
Cleaning the target dir fixed it. The next error:
|
On which exact step it fails? |
Yep assemble_fatjar webui. I have destroyed the Vagrant environment and am bringing it up again. |
Everything's been pushed now! |
printToFile(file)(_.println(content)) | ||
s"File [${file.getAbsolutePath}] was overriden successfully!".success | ||
} else { | ||
s"File [${file.getAbsolutePath}] was not modified".success |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Open question: in the case where the file already exists and the content hasn't changed and the force flag is set, should we be modifying the date anyway to mark that the file has been updated recently and to make the behaviour of the force flag consistent (so that it always overwrites the file)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question. And I agree, we probably need to always override file with --force
flag.
@chuwy it looks good to me - I don't have any suggestions besides the file overwriting thing. |
19b112f
to
cdd7cc1
Compare
New features
--force
flag (Add force flag #141). Without it Schema Guru will not override any table definitions of migrations if there was any manual changes (ignoring comments and white spaces)Internal changes
input
argument is no more required be last, now we can add options after it (run schema --schema-by "$.path" {{input}} --enum 3
). As a downside, Spark job now receives just a flag--enum-sets
instead of multiple options (Problem running Spark Job with scopt in EMR scopt/scopt#103)Blog post: snowplow-archive/snowplow.github.com#292