Capability to reuse and extend yaml boilerplate

[KostasKgr]

I have been trying to find a way to reuse boilerplate base yaml definitions to build on more complicated tasks.

Some good examples of how this could look like are the following:

• Gitlab extends: https://docs.gitlab.com/ee/ci/yaml/#extends
• Gitlab !reference https://docs.gitlab.com/ee/ci/yaml/yaml_optimization.html#reference-tags

I will use the gitlab functionality as an example for implementing the base and extended functionality of installing packages only if the requested package version has changed.

.cache:
  version: echo $VERSION > ~/.cache/tasksetup/{{.TASK}}.txt
	

tasks:
  .run_once_per_version:
    description: Pattern to run command once per a specified version
    deps: [setup]
    platforms: [linux]
    status:
      - test $(cat ~/.cache/tasksetup/{{.TASK}}.txt) -eq $VERSION


  install_docker:
    extends: .run_once_per_version
    cmds:
	    - # commands to install docker $VERSION
	    
	    # reference would insert multiple cmds if the value was a list
	    - !reference[.cache, version]
    env:
      VERSION: 27.3.1


  setup:
    internal: true
    run: once
    cmds:
      - mkdir -p ~/.cache/tasksetup/
    status:
      - test -d ~/.cache/tasksetup/

Gitlab has two additional sections that help a lot with extending, before_script and after_script. If after_script was available then it would make it easier to not have to remember to add the cache version directive every time.

---

Have you run into this use case? How do you implement it usually? Would the capability to extend a base definition be of benefit here?

p.s.

Some more complicated examples would be uses of kustomize in kubernetes manifests. While not very simple in nature, there should be relevant go code available for implementing a strategic merge.

• Kustomize to edit helm charts https://fluxcd.io/flux/components/helm/helmreleases/#post-renderers
• https://kubectl.docs.kubernetes.io/references/kustomize/kustomization/patches/

[trulede]

But you can just use 'deps', 'run', and lets say, 'includes' with a bunch of simple tasks. Then you just let Task take care of figuring it out (reality check, you will spend some time figuring it out too).

Think about the problem as A depends on B depends on C ... rather than Before (A) and After (C) ... and you get there.