fix(database)!: use transactions tied to repo counters for hook and build to avoid collisions #1353
  Add this suggestion to a batch that can be applied as a single commit.
  This suggestion is invalid because no changes were made to the code.
  Suggestions cannot be applied while the pull request is closed.
  Suggestions cannot be applied while viewing a subset of changes.
  Only one suggestion per line can be applied in a batch.
  Add this suggestion to a batch that can be applied as a single commit.
  Applying suggestions on deleted lines is not supported.
  You must change the existing code in this line in order to create a valid suggestion.
  Outdated suggestions cannot be applied.
  This suggestion has been applied or marked resolved.
  Suggestions cannot be applied from pending reviews.
  Suggestions cannot be applied on multi-line comments.
  Suggestions cannot be applied while the pull request is queued to merge.
  Suggestion cannot be applied right now. Please check back later.
  
    
  
    
I hesitate to say "fixes" for go-vela/community#997 and go-vela/community#213 because at very very high concurrency (300 simultaneous webhooks for one repo), it's still possible to see this issue I noticed. However, these changes can handle a great deal more concurrency compared to
main.In my testing, I was able to send 30+ webhooks simultaneously and 300+ with a .25 second delay and not run into duplicate key issues.
The key difference here is removing fetches for counters and instead tying the repo counters to the create functions for hooks and builds.
This PR also forces the worker's substitution routine to play a critical role in rendering any env vars containing the build number. This breaks situations in templates when teams use those specific Vela platform vars in a sprig func like
{{ vela "BUILD_NUMBER" }}This should really just be
${VELA_BUILD_NUMBER}, but if a user is — for whatever reason — performing some sort of inline Go logic based on build number, this would be a regression for them.