The problem is that, for some reason, the new release of MacOs has reset settings of the packet filtering.

Check if it has the correct value (should be 1):

# Check if packet forwarding is enabled
sysctl net.inet.ip.forwarding

Otherwise set it correctl:

sudo sysctl -w net.inet.ip.forwarding=1

Correctly handling certain use cases requires that containers running under Docker properly receive and handle sent signals. It comes to mind graceful process termination when systemd will send a SIGTERM to the process giving it a chance to cleanly stop before it’s being sent a SIGKILL that results in immediate process stop. Handling signals in this case is quite simple and well-documented, either using the newer sigaction function or the older signal. However, if the process ran by systemd is in fact a Docker container then things are not so simple.

The Docker daemon will forward signals to the process running inside the container with PID=1. When running outside a container, that’s usually process init, the root of all the process hierarchy. Inside a container, however, the process, may or may not be the root process (thus having PID = 1).

Example: Dockerfile using the shell form for CMD or ENTRYPOINT:

CMD “echo ‘hello world’”
ENTRYPOINT “echo ‘hello world’”

These will result in an execution under the shell:

/usr/bin/bash -c “echo ‘hello world’”

What this means is that the shell process (bash here) will have PID=1, therefore it is the shell that will get signals sent by Docker. The “echo” process running above will not receive those signals.

exec form

What is recommended in this case is running the exec form for CMD or ENTRYPOINT where the arguments are inside a JSON array, as below:

CMD [“echo”, “hello world’]
ENTRYPOINT [“echo”, “hello world”]

Now the echo process will have PID=1 and will properly receive all the signals. This works very well. Unless, the shell is needed.

Environment variable substitution

Environment ariable substitution for environment variables declared as ENV in the Dockerfile does not work with exec form. A shell would be needed in order to perform that substitution.

What’s needed is a custom process that properly forwards signals to children processes, but that also properly does variable substitutions and passes expanded environment variables to launched children processes.

Check the init2 for a possible solution.

There are times when it’s interesting to disable the possibility to merge a merge request. The merge request might be in a mirrored repository, or you might just prefer manually merging branches.

Solution

The “Merge” button behaviour (enabled/disabled) is driven by the method isMergeButtonDisabled which returns a boolean indicating whether the merge button should be disabled or not.

The cleanest way to modify this behaviour is to tinker with the Vue files that Gitlab comes with. However, since these components are not served directly (they are compiled and bundled using webpack) this means that compilation is needed, which might be a hassle.

The other way is to modify the webpack bundle directly. The instructions below are for a self-hosted Gitlab instance, Debian install, version 15.8. But they probably apply with minimal modifications to Omnibus as well.

Warning: At this point I’m assuming you know what you’re doing, or otherwise you risk crippling your Gitlab installation.

Your mileage may vary but my bundle is stored in /var/lib/gitlab/public/assets/webpack (this is a Debian distrib Gitlab). Go into this directory and do:

grep isMergeButtonDisabled * | cut -f1 -d:

A match should be in a file called pages.projects.merge_requests.show.*.chunk.js. Edit this file (make sure to do a backup first), search for isMergeButtonDisabled. Change the function to read instead of:

isMergeButtonDisabled(){const{commitMessage....

to:

isMergeButtonDisabled(){return true;const{commitMessage....

Don’t forget to remove the pages.projects.merge_requests.show.*.chunk.js.gz as otherwise that one will be served instead of the modified version. Alternatively you can also use gzip in order to replace the existing archive.

Need help with setting up Gitlab? Contact us at www.snowlinesoftware.com for help.