1

I really could use a pre-pull/merge hook. It isn't because of the repo itself. It's because of what the repo interacts with. Equivalent behavior would be fine.

Example: Our repo controls a docker-compose file. If the name and/or tag for an image inside the file changes while the stack it controls is up, then docker-compose won't be able to bring down the stack/container. It isn't desirable to always require the stacks to come down before pulling.

What I would like is to have a pre-merge hook that checks to see if one of the relevant files would be changed in the merge. If so, it writes a message to the console like: "If your stacks are up, you should really take them down now (using stop.sh). Otherwise, you should merge later. Would you like to continue [C] or abort [A]?" The dev only has to enter "stop.sh" in another terminal and then hit C. This also alerts the dev that one or more of the stacks must have changed. I could even give a convenient list.

Note that we sometimes have more than one docker-compose file for a stack, and different sets of compose files might be invoked in different combinations, depending on the situation. The scripts that decide which ones to invoke might change, too. All these file changes would have to be tracked and handled in concert.

The docs say pre-merge-commit runs after the merge has happened. I could have the hook check what has changed, offer to the dev to force an abort, then have the dev take the stacks down, then merge again. This is not terrible, but the devs will prefer the pre-merge option. Is this doable?

My best idea for a workaround is to use a regex script to take down any dangling containers from the stack that aren't the current ones.

If there is some other way to handle this sort of situation, let me know. If you want to write in a pre-pull/merge hook, I volunteer to test!

PS - yes, I should teach all the peeps to inspect the fetch before they merge, but they're overworked humans, and I want to be nice.

phd
  • 82,685
  • 13
  • 120
  • 165
Lachele
  • 46
  • 1
  • 5
  • 1
    are you dealing with any hosting services like GitHUb/GitLab/BitBucket? Where do you want the checks to happen? on each developer's system or on the hosting service's side ? It appears you want to have a centralized management which would monitor developer's pushed changes and accordingly throw some appropriate message. – Asif Kamran Malick Mar 29 '21 at 08:07
  • 1
    Although it's *less* "user friendly" than the nonexistent hook you want, consider asking people not to use `git pull` / `git merge` here, but rather some script you write. The script can run `git fetch` (perhaps optionally), then do the work you'd do in a hook, then run `git merge`. The overall effect is the same as if you had the hook, except that they do have to remember to run CommandX instead of GitPull. – torek Mar 29 '21 at 08:55
  • 1
    @AsifKamranMalick - these checks need to happen on each developer's system. We already have pre-push hooks in place. This is different. – Lachele Mar 30 '21 at 06:40
  • 1
    @torek - your suggestion is reasonable. I will consult with the team to see what they think. thanks. – Lachele Mar 30 '21 at 06:42

0 Answers0