Create a sub-workflow "save to git"

Hey,

I have a bunch of workflows that end up creating new json files into a git repository.

the last step always involve the same steps of stringify the items, save as file, git add + git commit + git push. I’m trying to put them into a generic sub-workflow that I could call from the “content creator” workflows, but I’m a bit stuck:

beside the array of items, I need two extra “global” (ie that aren’t key in the items): the filename to create (that will contains the json.strinfigy of items) and the commit message.

Is there a way to set settings/parameters to workflow that are triggered?

My best workaround would be to add as a last step a function that would create a {filename:“test.json”, commit: “creating test.json”, data: JSON.stringify(items)} and use that as a param to the save to git subworkflow, but feels a bit cluncky, so I’m wondering if there is a way that fits more into the n8n design.

Last but not the least: debugging sub-workflows triggered from other workflows is not a very smooth experience and a bit of a black box. Do you have a tip to share on how to dev subworkflows?

Tia

Hi @xavier

Is there a way to set settings/parameters to workflow that are triggered?

If you want to have additional fields available in a subworkflow (which I assume you are calling through the Execute Workflow node), you could simply put a Set node in front of the Execute Workflow one like so:

image

Example Workflow
{
  "nodes": [
    {
      "parameters": {},
      "name": "Start",
      "type": "n8n-nodes-base.start",
      "typeVersion": 1,
      "position": [
        240,
        300
      ]
    },
    {
      "parameters": {
        "values": {
          "string": [
            {
              "name": "aRandomAddedValue",
              "value": "Foo"
            }
          ]
        },
        "options": {}
      },
      "name": "Set",
      "type": "n8n-nodes-base.set",
      "typeVersion": 1,
      "position": [
        680,
        300
      ]
    },
    {
      "parameters": {
        "workflowId": "123"
      },
      "name": "Execute Workflow",
      "type": "n8n-nodes-base.executeWorkflow",
      "typeVersion": 1,
      "position": [
        900,
        300
      ]
    },
    {
      "parameters": {
        "functionCode": "return [...Array(10).keys()].map(i => {\n  return {\n    json: {\n      myValue: i + 1\n    }\n  }\n})"
      },
      "name": "Mock Data",
      "type": "n8n-nodes-base.function",
      "typeVersion": 1,
      "position": [
        460,
        300
      ]
    }
  ],
  "connections": {
    "Start": {
      "main": [
        [
          {
            "node": "Mock Data",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Set": {
      "main": [
        [
          {
            "node": "Execute Workflow",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Mock Data": {
      "main": [
        [
          {
            "node": "Set",
            "type": "main",
            "index": 0
          }
        ]
      ]
    }
  }
}

This example would just add a aRandomAddedValue field to each item and then passes everything on to the sub workflow (the sub workflow could then reference it using expressions like {{$json["aRandomAddedValue"]}}

Last but not the least: debugging sub-workflows triggered from other workflows is not a very smooth experience and a bit of a black box. Do you have a tip to share on how to dev subworkflows?

When developing sub workflows specifically, I tend to start with a Set node that mocks the data the workflow would receive from the main workflow. Here is a quick real world example of how that looks like:

I know this sub workflow will receive two fields (operation and email) from the parent. To be able to test it independently, I am using a Set node including these two fields and an expression such as {{$json["email"] || "[email protected]"}}. So when this workflow is called by the parent workflow, the node will just use the email passed on by the parent, but when running the workflow manually (during development), it uses a mock value of [email protected] allowing me to play around with everything.

I hope this helps! Let me know if I missed anything :slight_smile: