{"id":3486,"date":"2026-11-02T15:00:00","date_gmt":"2026-11-02T07:00:00","guid":{"rendered":"https:\/\/www.olares.com\/articles\/?p=3486"},"modified":"2026-10-27T14:57:01","modified_gmt":"2026-10-27T06:57:01","slug":"nocodb-log-tool-release-updates","status":"publish","type":"post","link":"https:\/\/www.olares.com\/articles\/nocodb-log-tool-release-updates\/","title":{"rendered":"Turn Tool Release Updates Into a Reviewable NocoDB Log"},"content":{"rendered":"

A release log is useful when it preserves the source and separates fetched information from a human decision. Use n8n to fetch a GitHub release and store it in NocoDB, but look for an existing record before creating a row. Use the repository plus GitHub\u2019s release ID as the match key, and set Needs review<\/strong> only when creating a new row.<\/p>\n

Define the table and its match key<\/h2>\n

This is a workflow design to build and test on your own instance. Node labels and available filter controls can vary by version. Create these columns before wiring the automation; keep the source fields separate from the review fields.<\/p>\n

\n\n\n\n\n\n\n\n\n\n\n\n\n
Column<\/th>\nValue to store<\/th>\n<\/tr>\n<\/thead>\n
Release key<\/td>\nOwner\/repository + a separator + the release id<\/code>, stored as text.<\/td>\n<\/tr>\n
Repository<\/td>\nThe configured owner\/repository; normalize the spelling consistently.<\/td>\n<\/tr>\n
Version<\/td>\ntag_name<\/code>, not the optional display name.<\/td>\n<\/tr>\n
Published<\/td>\npublished_at<\/code>.<\/td>\n<\/tr>\n
Release notes<\/td>\nbody<\/code>; handle an empty value.<\/td>\n<\/tr>\n
Source link<\/td>\nhtml_url<\/code>.<\/td>\n<\/tr>\n
Review status<\/td>\nNeeds review<\/strong> on creation; preserved on later runs.<\/td>\n<\/tr>\n
Review notes<\/td>\nHuman notes; never overwritten by the fetch step.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

Keep the GitHub release ID separate from NocoDB\u2019s row ID. The first identifies the release; the second identifies the row to update. Configure a unique constraint on Release key if your table and deployment support it. A lookup followed by Create alone can race if two executions run at once.<\/p>\n

Fetch one release manually<\/h2>\n
    \n
  1. Start with a Manual Trigger and an HTTP Request node. Use GitHub\u2019s latest-release endpoint<\/a>: GET \/repos\/{owner}\/{repo}\/releases\/latest<\/code>. Substitute the repository you want to follow.<\/li>\n
  2. Inspect a successful response before mapping it. This endpoint returns the latest qualifying published release, excluding drafts and prereleases. It is not a complete release history.<\/li>\n
  3. In Edit Fields, map the response fields in the table and construct Release key from the configured repository and id<\/code>. Keep the release object available for the Create branch after the lookup.<\/li>\n
  4. Stop without writing a row if required fields are missing or the request fails. A 404 can mean no qualifying release, a wrong repository path, or inaccessible private content. A timeout or rate-limit response is not a new release.<\/li>\n<\/ol>\n

    Look up the row before creating it<\/h2>\n

    Follow n8n\u2019s NocoDB credential instructions<\/a>, using an endpoint reachable from the n8n server and a token authorized for the required table operations. The NocoDB node<\/a> documents separate Create, Get, Get Many, and Update operations; Create is not an upsert.<\/p>\n

      \n
    1. Use Get Many<\/strong> to find rows whose Release key exactly matches the constructed key. Configure the filter supported by your node version and inspect the returned data. If you filter after retrieval, fetch all required pages so a partial result cannot produce a false \u201cnot found.\u201d<\/li>\n
    2. Route by the match count. Zero matches may create a row; one match skips creation; more than one match stops for duplicate cleanup. Make the empty-result branch explicit: some node configurations emit no items when nothing matches, so a following IF node would otherwise never execute. Test that case and use the node\u2019s supported output settings or a separate aggregation branch.<\/li>\n
    3. For zero matches, map the stored release fields into Create<\/strong> and set Needs review. For one match, the simplest policy is to skip it. If you choose to refresh release notes later, use the existing NocoDB row ID and update source fields only, preserving review status and human notes.<\/li>\n
    4. On a timeout during creation, look up the key again before retrying: the first write may have succeeded. If a unique constraint rejects the insert, read the matching row and check it rather than blindly retrying Create.<\/li>\n<\/ol>\n

      Use a unique key at the storage layer when available, and avoid overlapping executions. If your deployment cannot enforce uniqueness, serialize this workflow and document that a read-before-create check is not an atomic guarantee.<\/p>\n

      \n\n\n\n\n\n\n\n\n
      Lookup result<\/th>\nAction<\/th>\n<\/tr>\n<\/thead>\n
      No match<\/td>\nCreate once; initialize review status.<\/td>\n<\/tr>\n
      One match<\/td>\nSkip, or update selected source fields while preserving review decisions.<\/td>\n<\/tr>\n
      Multiple matches<\/td>\nStop and resolve duplicate records.<\/td>\n<\/tr>\n
      Request or lookup failure<\/td>\nRecord the failure; do not create an incomplete row.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

      Test before adding a schedule<\/h2>\n