This document is to guide you on how to clone multiple RemoteTech repositories on a build server (e.g. AppVeyor
), compile source codes, package outputs, push the final package to an external platform such as GitHub.
Currently, the following list of RemoteTech repositories are
- RemoteTech-Complete is a centralised place where all RT components are pulled from their individual respositories and compiled.
- RemoteTech-Delay handles the signal delay calculations independently
- RemoteTech-Antennas contains antenna parts for Kerbel Space Program. These parts are capable to function in stock CommNet without requiring RemoteTech to work.
- RemoteTech-Common provides a suite of underlying common services and utilies to various major components of RemoteTech.
- RemoteTech-CommandHandler is RemoteTech Flight Computer with different functionalities. It is able to operate independently from the other RemoteTech components.
- RemoteTech-Transmitter handles the entire antenna system of RemoteTech mod.
- Visual Studio 2015
- Python 3.5 or greater
- Shell scripting
- Continuous integration service
- Certain KSP assembly files
- Git user authorisation for cloning, pulling and other operations
The scripts
folder contains all scripts and configuration files necessary to build a full RemoteTech release successfully.
build.bat
instructs Visual Studio compiler to locate and executeRemoteTech-Complete.sln
packager.py
is a package program to gather and package into a mod releasepackager_config.py
is a configuration generator and storage forpackager.py
RemoteTech-Complete.json
is a configuration file to be read bypackager.py
or generated bypackager_config.py
update_subtrees.sh
is a Bourne shell script, that performs Git pull operations on all component repositories of RemoteTech prior to a build execution
Currently, we use the pipeline script, appveyor.yml
, in the root directory to perform actions at various stages of the entire build process, such as pre-build, post-build and pre-package.
Sequence of major steps is as follows.
-
Perform configurations to a build environment
- choose Visual Studio 2015
- point to specific branch of the central repository
- set up environment path to Python 3.5
- set up Git user details
-
Clone GitHub central repository fully
-
Download and unzip the password-protected package of KSP assembly files to a temp folder
-
Call
update_subtrees.sh
to get latest changes from all component repositories -
Call
build.bat
to start the build process -
Call
packager.py
with relevant arguments to place resulting files into GameData folder and to zip the folder -
Deploy the release to a provider such as GitHub
-
Give a shout to KSP community on this release
-
Git subtree pull error
fatal: Not a git repository (or any of the parent directories): .git
Resolution: clone the central repository fully (not shallow copy) to make repository metadata available
-
Git subtree pull error
fatal: 'RemoteTech-Antennas' does not appear to be a git repository
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Workaround: It seems to be related to Git user authorisation/authentication stored in the last commit, I don't know why. Try use a remote UNIX environment to clone, make some commits and push to the central repository.
-
Strange aftermath result of Git subtree pull: directory of the central repository suddenly becomes the full directory of one component repository after running
update_subtrees.sh
.Resolution: it is due to the corrupt metadata of the component subtree. Do and commit these following commands.
git rm -r src/RemoteTech-Delay
git commit -m "Remove corrupt subtree directory"
git push origin develop
git subtree add --prefix=src/RemoteTech-Delay https://github.com/RemoteTechnologiesGroup/RemoteTech-Delay develop --squash
-
Invalid password when opening zip of KSP assembly files
Resolution: host your own files with own password and update the URL and encrypted password string in the pipeline script.
-
URL to zip of KSP assembly files is invalid
Resolution: host your own files somewhere else and point the build process to them. The current URL in the pipeline script can not be guaranteed for a long time.