Geodesic version 4 is a major release, with breaking changes and significant new features. (PR #961)

Please read the Release Notes for more details.

If you had customized your derivative of Geodesic to work with Spacelift, please pay special attention to the "Special notes for Spacelift Users" in the Breaking Changes section of the release notes. It has not been tested with Atlantis, as we no longer officially support it.

Highlights

Breaking Changes

Although we recommend a thorough review of the Breaking Changes in the referenced Release Notes, for most users, we expect no action will be needed to switch from Geodesic v3 to v4. The breaking changes generally only affect people who have heavily customized Geodesic, or who are using Geodesic to run Atlantis or Spacelift.

Geodesic configuration files previously had to be placed under $HOME/.geodesic. The can remain there indefinitely, but now they may alternatively be placed in $XDG_CONFIG_HOME/geodesic (defaults to $HOME/.config/geodesic). If any are found there, then anything under $HOME/.geodesic will be ignored.

Previously, preferences and overrides files (and the preferences.d directory) could be placed directly in the Geodesic configuration directory. Now they must be placed in the defaults subdirectory (e.g. $XDG_CONFIG_HOME/geodesic/defaults/) or a Docker image-specific subdirectory. The history file is the only file that can be placed directly in the configuration directory.

Because Geodesic needs to locate the configuration files before it can read them for configuration, you cannot configure where the configuration files are located other than by setting $XDG_CONFIG_HOME.

Geodesic always mounts the current working directory from the host into the container. Previously, it also mounted the host's $HOME directory into the container as well. It no longer does that, because that can cause significant performance issues. (For example, on macOS, Docker's virtual disk is (several levels) under the $HOME directory, causing perpetual changes to be synced.) So do not launch Geodesic from your $HOME directory. Change to the root of your source directory first and launch it from there. (Even better, set WORKSPACE_FOLDER_HOST_DIR to the root of your source directory in launch-options.sh.)

New Features

Again, there is a lot more information in the Release Notes, and also updated documentation about customization and new documentation about Geodesic's configuration via environment variables. We list here only some of the more significant changes.

• Exiting the first shell that launched Geodesic no longer kills all the other running shells. Fixes #774
• By default, running the geodesic command multiple times will launch multiple shells into the same container. Now you have the option (--solo, ONE_SHELL=true) of launching each shell into a separate container.
• If you are running multiple shells in one container (the default), you can no longer detach from the shell using Ctrl-P,Ctrl-Q (or your customized detachKeys setting). This is for 2 reasons. First, there is no way to reattach to a shell once detached from it, and second, Ctrl-P is used in command-line editing, and allowing it to be used as part of a detach sequence interferes with that.
• While previously there were multiple options for customizing the Geodesic shell, there had been no options other than setting shell environment variables for customizing the launch of the Geodesic Docker container itself. Now you can create a launch-options.sh file to configure the launch without having to pollute all your shells with extra environment variables.
• geodesic help lists the major command-line options. Environment variables can also be set on the command line using the format --var=value.
• geodesic stop cleanly shuts down all the shells in the container, then the container itself. Much preferable to docker kill.
• Geodesic shells now exit cleanly in most cases, meaning you can run scripts inside Geodesic on exit via trap script EXIT.
• New hooks have been added to the wrapper to run on shell exit or on container exit, based on the wrapper's view of what happened when it exits. It is not foolproof, but it can be handy for things like updating window titles where it is not a big issue if they are not run or are run at the wrong time.