The current behaviour of GitExperience Webhooks with GitHub does not provide a very developer experience for anything other that simple scenarios.
The webhook currently takes events from GitHub (pull requests), and based on the diff of the commit, it will:
  • Create a new Harness object if there is a new file in the diff
  • Update a Harness object if there is a modified file in the diff
  • Delete a Harness object if there a removed file in the diff
There are a number of problems with this behaviour, including but not limited to:
  • Deletion of a file and creation of an almost similar file in the same commit shows up in the diff as an update rather than a deleted file and a new file.
  • Deletion of a file does not fully remove the object in the Harness UI (the support ticket I raised states this is because the webhook doesn't update the Harness database).
  • Updating the name or identifier of an existing Harness object leaves the object in a stale state where the display name and identifier show in the UI under the old name but the YAML shows the updated values (this again I assume to be a database update issue)
  • Updating files whose 'new object' event errored for any reason (an example would be an invalid identifier when the file is first created) fails to create the object as it treated as an update to an object that doesn't exist; the solution to this involves a change to delete the file(s) then a subsequent change to re-add them back in and is a painful experience when changes require approval.
  • Creating and then updating a second file with the same content (critically the same identifier) as an existing Harness object treats this as an update to the existing object.
The expectation for the behaviour is that the webhook should treat the GitHub repository as the source of truth for all objects, and should compare the current set of tracked files with the inventory of the Harness project. It should create its own diff based on that context, and perform the appropriate action(s) to ensure that the Harness project's objects match those in the GitHub repository (errors excluded). Critically, it should also reflect changes in the database where required to keep this in line.