4.3 n8n (API)

• Type: n8n API node (HTTP or dedicated n8n API integration, depending on your setup).
• Purpose: Retrieves all workflows from your n8n instance.
• Behavior:
  • Calls the n8n API endpoint that lists workflows.
  • Outputs an array of workflow objects, each containing metadata and the workflow definition.
• Credentials:
  • If your n8n instance requires authentication, configure:
    • API key authentication, or
    • Basic auth credential (username and password).
  • Attach this credential to the n8n API node so it can successfully list workflows.

4.4 SplitInBatches / ForEach

• Type: SplitInBatches node (often used as a ForEach pattern).
• Purpose: Iterates over each workflow returned by the n8n API.
• Behavior:
  • Processes workflows one at a time or in small batches.
  • Feeds each individual workflow into the Gitea-related nodes for file existence checks and updates.
• Notes:
  • Batch size can be tuned for performance or API rate limits.
  • For large numbers of workflows, batching helps prevent timeouts or rate-limit issues.

4.5 GetGitea (HTTP Request GET)

• Type: HTTP Request node.
• Method: GET.
• Purpose: Checks whether a JSON file for the current workflow already exists in the Gitea repository.
• Endpoint pattern:
  • Constructed from repo.url, repo.owner, repo.name, and the workflow name.
  • Target file path: <workflowName>.json.
• Expected results:
  • 200 OK: File exists. Response includes:
    • sha – the current file SHA in Gitea.
    • content – base64-encoded file content.
  • 404 Not Found: File does not exist in the repository.
• Credentials:
  • Uses the HTTP Header Auth credential with:
    • Header name: Authorization.
    • Header value: Bearer YOUR_PERSONAL_ACCESS_TOKEN (including the space after Bearer).

4.6 Exist (IF)

• Type: IF node.
• Purpose: Branches the flow depending on whether the workflow file exists in Gitea.
• Logic:
  • If the GET request succeeded (file found), follow the “file exists” branch.
  • If the GET request indicates a 404 (file missing), follow the “file does not exist” branch.
• Resulting branches:
  • Non-existent file:
    • Passes data to SetDataCreateNode then Base64EncodeCreate and finally PostGitea.
  • Existing file:
    • Passes data to SetDataUpdateNode then Base64EncodeUpdate and then to Changed and PutGitea if needed.

4.7 SetDataCreateNode (Set)

• Type: Set node.
• Purpose: Prepares the data structure for creating a new file in Gitea.
• Responsibilities:
  • Extracts the workflow JSON from the current item.
  • Sets any required fields for the create payload that the encoding node and HTTP POST will use.

4.8 SetDataUpdateNode (Set)

• Type: Set node.
• Purpose: Prepares the data structure for updating an existing file in Gitea.
• Responsibilities:
  • Retrieves the existing file’s sha from the GetGitea response.
  • Combines the workflow JSON with the current file metadata to build an update-ready payload.

4.9 Base64EncodeCreate / Base64EncodeUpdate (Code)

• Type: Code nodes.
• Purpose: Transform workflow JSON into pretty-printed JSON and base64-encode it for the Gitea API.
• Conceptual logic:

# Process (conceptual)
json_string = json.dumps(workflow_json, indent=4)
base64_string = base64.b64encode(json_string.encode('utf-8')).decode('utf-8')
# returned payload contains: content (base64 string)

• Behavior:
  • Accepts the raw workflow JSON.
  • Pretty-prints it with indentation for human readability in the repository.
  • Encodes the result to base64 so it can be sent in the Gitea API request body.
  • For updates, also ensures the sha field is present so the PUT request is valid.
• Output:
  • At minimum, a content field containing the base64-encoded JSON string.
  • For updates, a sha field that matches the current file version in Gitea.

4.10 PostGitea (HTTP Request POST)

• Type: HTTP Request node.
• Method: POST.
• Purpose: Creates a new JSON file in the Gitea repository when it does not already exist.
• Payload:
  • Includes the base64-encoded content from Base64EncodeCreate.
  • May include additional fields required by Gitea such as commit message, depending on your configuration.
• Credentials:
  • Uses the same HTTP Header Auth credential as GetGitea and PutGitea.

4.11 Changed (IF)

• Type: IF node.
• Purpose: Determines whether the file content in Gitea differs from the newly encoded workflow content.
• Logic:
  • Compares the existing base64 content from the GetGitea response with the new base64 content produced by Base64EncodeUpdate.
  • If the content is identical, the workflow skips the update to avoid unnecessary commits.
  • If the content is different, the workflow proceeds to PutGitea to commit an update.

4.12 PutGitea (HTTP Request PUT)

• Type: HTTP Request node.
• Method: PUT.
• Purpose: Updates an existing JSON file in the Gitea repository when changes are detected.
• Payload:
  • Includes:
    • content – the new base64-encoded JSON.
    • sha – the current file SHA from the previous GET response.
  • Gitea uses the SHA to detect conflicting updates and maintain history integrity.
• Credentials:
  • Reuses the Gitea HTTP Header Auth credential.

5. Configuration Steps

5.1 Configure global repository variables

In the Globals (Set) node, define your Gitea repository details:

• repo.url → for example https://git.yourdomain.com
• repo.name → for example workflows
• repo.owner → your Gitea username or organization name

These values are used to construct API URLs