Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clean up output, implement timeout, do not update the whole index when deploying a branch #127

Open
wants to merge 10 commits into
base: master
Choose a base branch
from

Conversation

GiedriusS
Copy link

@GiedriusS GiedriusS commented Apr 9, 2019

Some set of fixes that I've done to make g10k usable on a large deployment:

  • Do not lock modify whole index when deploying a specified branch (main use-case). Achieve this by using git fetch ... instead of doing git remote update --prune each time if we are interested only in one branch. Races are very common when trying to update all of the refs. Errors can still happen however because the webhook uses one goroutine it is very unlikely (imagine an event listener that fires off g10k deployments). Also, if one or more deploys when there >1 concurrent deploys at the same time will fail then it's not the end of the world because the one which "caught" the newest ref will succeed. Still do an initial git remote update --prune to download all of the refs and branches.
  • Implement the timeout functionality. Make proper contexts and pass them to CommandContext()
  • Add a proper debug output with the command name + output + the error

Verification:

  • The tests pass
  • Battle-tested on a huge deployment (:

Pardon me if my coding style is bad or I did some mistakes.

Giedrius Statkevičius added 8 commits April 9, 2019 15:45
Update doMirrorUpdate to be able to pass a branch name to it. Pass an
empty branch when we want to deploy the whole thing, and pass only a
specific branch when `-branch=...` has been specified. `git fetch` does
not lock the whole index and only pulls down the branch which avoids the
whole plethora of issues when more than one instance of g10k is running.
For example, we could run into issues like this when `git remote update
--prune` is running more than once:

error: Ref refs/heads/test is at 1d793f181f3a460916ce1ab5dc33e007622a9a61 but expected c28d866fdfed5be79f5ea453e04ce887627a8efa
! c28d866..1d793f1  test -> test (unable to update local ref)

Also, avoiding updating the whole index means that the performance
significantly improves. In my testing the whole time it takes to deploy
a branch has been reduced by about 10 seconds.
Update executeCommand() to leave output intact by separating two
different concerns: the error and the output itself. Still always set
the returnCode to 1 if any error has occurred.
`timeout` is passed now down to executeCommand() but nothing is done
with it. Properly make a context and pass it to exec.CommandContext().
Also, while at it add proper debug printing so that output messages
*and* the error would appear in the console if `-debug=true` is
specified.
Otherwise we might run into an error like this:

From https://git.foo.bar/lol.git
 ! [rejected]        dimstoperms -> dimstoperms  (non-fast-forward)
@@ -200,7 +216,6 @@ func executeCommand(command string, timeout int, allowFail bool) ExecResult {
}
} else {
er.returnCode = 1
er.output = fmt.Sprint(err)
Copy link
Owner

@xorpaul xorpaul Apr 16, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why don't you want to print the error output if there was an error?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The error and the program's output are two different things. We don't want to overwrite the actual output if it was there and that's why another field, err has been introduced to ExecResult.

@xorpaul
Copy link
Owner

xorpaul commented Apr 16, 2019

Cool stuff!

I'll verify your changes later when I have more time available.

xorpaul added a commit that referenced this pull request Sep 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants