Tree mapping - transform YAML from one format to another

[abitrolly]

As a Devops I often need to convert between CI config formats. For example, AppVeyor below to GitHub Actions.

version: "{build}"

install:
- cmd: python -m pip install tox

build_script:
- cmd: python -m tox

Or it could be GitHub Actions to GitLab Pipelines.

Describe the solution you'd like
Well, a set of comby filters/rules that allow to match and convert parts of the tree one at a time. It is also important to visualize non-converted parts of the tree and preserve them between filters/rules. That's needed to ensure that conversion is complete and correct.

Just an idea.

[rvantonder]

Thanks for expressing a desire for YAML, you're not the first! I need to add support for parsing indentation to identify blocks. I'd be grateful if you could give me a concrete example of

convert parts of the tree one at a time

for your use case, which I could use to test the additions once I implement them.

[abitrolly]

In that particular case above I was not able to map version: {build}, because it is not needed for the epp. Two other lines translated into this script.

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

jobs:
  build:
    runs-on: windows-latest
    steps:
    - uses: actions/checkout@v2
    - name: install
      run: python -m pip install tox
    - name: build_script
      run: python -m tox

on is the required key. The values are to mimic the behaviour of AppVeyor.

[abitrolly]

convert parts of the tree one at a time

In this specific case the version part was not specifically converted and was lost. It did add any context to resulting file, or to the conversion process itself. That's bad.

version: "{build}"

The on part.

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

This one converts between implicit AppVeyor behavior (nothing or empty string in initial file) into explicit behaviour in resulting definition.

jobs:
  build:
    runs-on: windows-latest

Job name build is also comes out of nowhere here. It can not be two jobs named "install" and "build_script" as in initial YAML, because jobs in Actions do not share state by default. That's why a default job is needed. Maybe a name "default" would be better here. runs-on is also an explicit declaration for the platform that AppVeyor uses by default.

    steps:
    - uses: actions/checkout@v2
    - name: install
      run: python -m pip install tox
    - name: build_script
      run: python -m tox

uses is again an explicit step for implicit AppVeyor behavior. steps are directs mapping from initial YAML.

[abitrolly]

Converting parts of the tree one at a time.

1. Map default behaviour of initial platform (AppVeyor) into empty template for target platform
2. If behaviour is modified from default, change values for target platform template accordingly (there are only no strings matched, so no modifications are applied)
3. Add necessary wrappers for the content that is available to be mapped in the next step.
4. Map the content (command line commands in this case)

After every step there is an incomplete unusable file, which becomes usable only after the last step is over.

I even imagine the interface that allows to go from one step to another (like horizontal pager) and see which data is passed from one side to another, where the context comes from for each, and how it is transformed there.

[rvantonder]

Got it, thanks!