• 6 Posts
  • 16 Comments
Joined 3 years ago
cake
Cake day: July 31st, 2023

help-circle





  • … put those in separate scripts and call them from the YAML.

    This is exactly what I try to avoid, cause:

    1. many people (in my experience ) even don’t bother refactoring YAML spaghetti code to separate scripts and we end up unmaintainable codebase

    2. and even if one has to do such a refactoring what is the point of using YAML at all ?

    All I need just a collection of tasks/jobs written on languages of choice and I don’t need YAML “programming” language at all )

    PS And btw I don’t mind having a minimal amount of YAML as configuration layer and this is what is presented in DSCI, but only minimal ))



  • Ok, try to do it on GH actions, share states between tasks/jobs for example:

    tasks/task_one/task.py

    #!/usr/python3
    update_state({
      'out1' : 'out1 value',
      'out2' : 'out2 value'
    })
    

    tasks/task_two/task.py

    #!/usr/python3
    dict = get_state()
    print(dict["out1"])
    print(dict["out2"])
    

    Or share states between jobs:

    jobs/job1/task.py

    #!/usr/python3
    
    update_state({
      'out1' : 'out1 value',
      'out2' : 'out2 value'
    })
    

    jobs/job2/task.py

    dict = config()
    
    print(dict["_dsci_"]["job1"]["out1"])
    print(dict["_dsci_"]["job1"]["out2"])
    
    

    I can’t imagine how much boilerplate code (if this ever possible ) one needs to write to achieve that on YAML based pipelines (GH Actions/ etc)

    And don’t tell me about jobs artifacts ))