6/12/2017 9:10:11 PM
guide
"By default, Gradle uses the name of the directory it finds the settings.gradle as the name of the root project. This usually doesn't cause problems since all developers check out the same directory name when working on a project. On Continuous Integration servers, like Jenkins, the directory name may be auto-generated and not match the name in your VCS. For that reason, it's recommended that you always set the root project name to something predictable, even in single project builds. You can configure the root project name by setting rootProject.name.
"
https://docs.gradle.org/current/userguide/intro_multi_project_builds.html
|
|
|
6/12/2017 6:41:01 PM
azkaban prefix is redundant and requires unnecessary
typing.
Keep the azkaban prefix in the jar file name.
|
6/12/2017 5:01:58 PM
3.28.0
reverts commit ffd9ebd.
The problem is not in the "fails fast" strategy per se, but there's another bug that would cause a job in a subflow to fail instead of running it, when two subflows contain jobs of the same name. It's because current DB record key for executable node is (execution id, job id, attempt). So the problem only happens when two subflows contain two jobs with the same name.
|
6/12/2017 2:45:52 PM
to consider allowsOnDuplicateKey since the original Azkaban database modules has this.
|
6/12/2017 2:32:25 PM
warning (#1215)
http://errorprone.info/bugpattern/ImmutableEnumChecker
|
|
|
6/12/2017 12:40:43 AM
even if test runner is slow (like supposedly on Travis sometimes)
This doesn't make the tests any slower than before, as long as they pass
Why would this help? Even locally the FlowRunner tests started failing when I put 10 instead of 100 max tries (10 ms wait per try). 1000 should make it pretty robust :)
For background, see:
PR #1179 (comment)
https://travis-ci.org/azkaban/azkaban/builds/240580566?utm_source=github_status&utm_medium=notification
PR #1201 (comment)
PR #1186
|
|
|
6/12/2017 12:06:02 AM
sleep for 20 seconds and the comments are wrong.
When debugging the test, the test would fail since it is time sensitive.
Fix:
Switch to use Jodatime utility to get the current time and manipulate the time in the test.
It's better to use the java time api and use a Guice injected wrapper class to manipulate time. However given that BasicTimeChecker is scheduled to be deprecated soon. It's not worth investing in it now.
|
