From 13ee1474a84198fdb9e24a3f0024504b283708cf Mon Sep 17 00:00:00 2001 From: Lukas Tenbrink Date: Thu, 31 Jul 2025 14:14:08 +0200 Subject: [PATCH] Fix the building releases docs formatting. --- maintainers/building_releases.rst | 61 +++++++++++++++---------------- 1 file changed, 29 insertions(+), 32 deletions(-) diff --git a/maintainers/building_releases.rst b/maintainers/building_releases.rst index f531cba..414eee7 100644 --- a/maintainers/building_releases.rst +++ b/maintainers/building_releases.rst @@ -116,25 +116,23 @@ Each of these is checked out on the relevant branch of ``godot-build-scripts``. Older branches may have slight variations to the workflow described above. -Some files in these folders are ``.gitignore``\ d but quite important: - -``config.sh`` is generated by copying ``config.sh.in`` and filling in -the blanks. It contains all the details needed to sign, notarize and -publish our builds. It’s also the file which defines which image -version/tag we’re using for those builds (e.g. ``4.3-f40``). - Signing -keys for various platforms. +Some files in these folders are ``.gitignore``\ d but quite important: + +* ``config.sh`` is generated by copying ``config.sh.in`` and filling in the blanks. It contains all the details needed to sign, notarize and publish our builds. It’s also the file which defines which image version/tag we’re using for those builds (e.g. ``4.3-f40``). +* Signing keys for various platforms. Building the binaries ~~~~~~~~~~~~~~~~~~~~~ The entry point to make builds is ``build.sh``, which is responsible -for: - Downloading the dependencies in ``deps`` if missing. \* Note: If -you update dependencies in the script or at their download location, the -easiest way to ensure things are up-to-date is to delete ``deps`` and -let ``build.sh`` download everything again. - Cloning the Godot Git repo -in ``git`` (only needed the first time). - Validating that the specified -branch or commit matches the version we claim to build with ``-v``. - -Creating a tarball of the Godot branch or commit we specify with ``-g``. -- Starting builds for all platforms sequentially. +for: + +* Downloading the dependencies in ``deps`` if missing. + * Note: If you update dependencies in the script or at their download location, the easiest way to ensure things are up-to-date is to delete ``deps`` and let ``build.sh`` download everything again. +* Cloning the Godot Git repo in ``git`` (only needed the first time). +* Validating that the specified branch or commit matches the version we claim to build with ``-v``. +* Creating a tarball of the Godot branch or commit we specify with ``-g``. +* Starting builds for all platforms sequentially. Builds are done by invoking ``podman`` (RedHat’s better Docker interface) with relevant arguments and the respective scripts found in @@ -182,10 +180,12 @@ Finally, the ``publish-release.sh`` script takes care of: - Publish the NuGet packages to NuGet Gallery. - Publish the Android library to MavenCentral. -For stable builds only, it additionally uploads the release to: - GitHub -at https://github.com/godotengine/godot \* This requires getting a -GitHub write token for one of our accounts. @GodotBuilder doesn’t have -write access to godotengine/godot for safety. - Steam - EGS - itch.io +For stable builds only, it additionally uploads the release to: +* GitHub at https://github.com/godotengine/godot + * This requires getting a GitHub write token for one of our accounts. @GodotBuilder doesn’t have write access to godotengine/godot for safety. +* Steam +* EGS +* itch.io On Steam, EGS, and itch.io, the builds need to be published manually in their respective backends (including writing a release post for Steam @@ -211,22 +211,19 @@ the ``screen`` session, disconnect, and later on reconnect and re-attach to the ongoing ``screen`` session which will have continued on the remote host. -Basic commands to know: - ``screen``: Start a session. - ``screen -r``: -Resume a previously detached session. If more than one are detached, -you’ll need to specify a PID after ``-r``. - ``screen -r -d``: Resume a -session that wasn’t properly detached (e.g. due to the connection timing -out). - ``exit`` (within a ``screen`` session): Terminate the session, -or if multiple virtual terminals were open, close the current one. +Basic commands to know: + +* ``screen``: Start a session. +* ``screen -r``: Resume a previously detached session. If more than one are detached, you’ll need to specify a PID after ``-r``. +* ``screen -r -d``: Resume a session that wasn’t properly detached (e.g. due to the connection timing out). +* ``exit`` (within a ``screen`` session): Terminate the session, or if multiple virtual terminals were open, close the current one. Within a ``screen`` session, commands can be issued using the Ctrl+A hotkey. This hotkey starts an input mode without visual feedback, which -can take notably these commands: - C: Create a new virtual terminal in -the current session. - D: Detach from the current session. - 0-9: Go to -the n-th virtual terminal. When creating a new session, there is only -one virtual terminal (0), but after using the C command, you can cycle -between 0 and 1, etc. \* This is useful when one virtual terminal is -busy with a multi-hour build, but you still want to do some checks in a -separate terminal (e.g. ``tail -n 1 out/logs/*`` to review the -progress). +can take notably these commands: +* ``C``: Create a new virtual terminal in the current session. +* ``D``: Detach from the current session. +* ``0-9``: Go to the n-th virtual terminal. When creating a new session, there is only one virtual terminal (0), but after using the C command, you can cycle between 0 and 1, etc. + * This is useful when one virtual terminal is busy with a multi-hour build, but you still want to do some checks in a separate terminal (e.g. ``tail -n 1 out/logs/*`` to review the progress). See ``man screen`` for more details and possibly cool tricks.