The module’s name will be the name of the git repo, however there are chances that the name could be conflicted, for example: * other people could publish the same named module * if you use a local directory as module * if you checkout a git repo but the module sits in one of its sub directories
version: 1.0.0
Verbose: v
MaxCallLayers: 8
RefDir: .
TaskFile: up.yml
ConfigDir: .
ConfigFile: upconfig.yml
Modules:
#if there is no repo, then it will use the dir as module and incorporate as module
- dir: hello-module/
alias: hello
notes:
- test module list
tasks:
-
name: Main
desc: main entry
task:
-
func: call
desc: |
note that the module dir is: hello-module, but in upconfig.yml you give the alias hello as module name
do: hello.Say_world
tasks:
-
name: Main
desc: main entry
task:
-
func: shell
desc: main job
do:
- echo "hello "
-
func: call
do: Say_world
-
name: Say_world
task:
-
func: cmd
do:
-
name: print
cmd: " .... world from Say_world"
loading [Config]: ./tests/modtests/0007/upconfig.yml
Main config:
Version -> 1.0.0
RefDir -> ./tests/modtests/0007
WorkDir -> refdir
AbsWorkDir -> /up_project/up/tests/modtests/0007
TaskFile -> up.yml
Verbose -> v
ModuleName -> self
ShellType -> /bin/sh
MaxCallLayers -> 8
Timeout -> 3600000
MaxModuelCallLayers -> 256
EntryTask -> Main
ModRepoUsernameRef ->
ModRepoPasswordRef ->
work dir: /up_project/up/tests/modtests/0007
-exec task: Main
loading [Task]: ./up.yml
module: [self], instance id: [dev], exec profile: []
Task1: [Main ==> Main: main entry ]
-Step1: [
note that the module dir is: hello-module, but in upconfig.yml you give the alias hello as module name
]
WARN: [config file does not exist] - [use builtin defaults]
loading [Task]: ./up.yml
module: [hello], instance id: [nonamed], exec profile: []
WARN: [*be aware*] - [both instance id and exec profile are not set]
=>call module: [hello] task: [Say_world]
Task2: [TODO: Main Caller Taskname ==> Say_world: ]
-Step1:
~SubStep1: [print: ]
.... world from Say_world