treasure-data / digdag

Workload Automation System
https://www.digdag.io/
Apache License 2.0
1.3k stars 221 forks source link

digdag init should set default timezone #31

Closed danielnorberg closed 8 years ago

danielnorberg commented 8 years ago
$ digdag --version
0.5.9
$ digdag init foo
2016-04-11 14:42:38 -0700: Digdag v0.5.9
  Creating foo/digdag
  Creating foo/.digdag-wrapper/digdag.jar
  Creating foo/.gitignore
  Creating foo/tasks/shell_sample.sh
  Creating foo/tasks/repeat_hello.sh
  Creating foo/tasks/__init__.py
  Creating foo/digdag.yml
Done. Type `cd foo` and `./digdag r` to run the workflow. Enjoy!
$ cd foo
$ digdag push foo -r test
2016-04-11 14:42:52 -0700: Digdag v0.5.9
Creating digdag.archive.tar.gz...
Exception in thread "main" io.digdag.client.config.ConfigException: timezone: parameter is required but not set at digdag.yml. Example is 'timezone: America/Los_Angeles'.
    at io.digdag.cli.client.Archive.runArchive(Archive.java:152)
    at io.digdag.cli.client.Archive.archive(Archive.java:105)
    at io.digdag.cli.client.Push.push(Push.java:66)
    at io.digdag.cli.client.Push.mainWithClientException(Push.java:41)
    at io.digdag.cli.client.ClientCommand.main(ClientCommand.java:55)
    at io.digdag.cli.Main.main(Main.java:176)
frsyuki commented 8 years ago

I still wonder whether timezone should be included in workflow definition or not... If a workflow is intended to be shared by other workflows as a library, the workflow shouldn't have timezone. So, applications and libraries have different requirements. Right now, digdag push requires you to put timezone config in the config file. This is useful when you can't restrict who deploys your workflow to production. Another idea is that digdag push requires --timezone option.

frsyuki commented 8 years ago

workflow.yml includes timestamp: UTC since 0.7.0.