GitHub CI Windows Configuration

GitHub CI Windows Configuration

GitHub Action

Continuous integration can be regarded as a workflow combined with several actions. Many operations are similar in different projects and can be shared completely, such as copy code, set basic environment, etc. GitHub allows developers to create actions with scripts, so If you need an action, you can directly use other people’s actions or create your own action.

GitHub Action Key Concepts：

• workflow ：A custom automated processes that you can set up in repository to build, test, package, release, or deploy any project on GitHub. A workflow can contains several jobs.
• job ：One job can be divided into several steps.
• step： One step can execute a series of actions.
• action ：minimum execute unit.

Workflow File

The configuration file of GitHub Action is called Workflow file stored in .github/workflows directory. Workflow file is YAML file and as long as GitHub finds a .yml file in the .github/workflows directory, it will automatically run the file. For more detailed , please refer to Official Document. A simple example of Workflow file is shown below:

# customized name of workflow, default name is as same as filename.
name: Greeting from Mona
# determine which envent will trigger workflow
on: push
# jobs.<job_id>.properties
jobs:
  # job_id
  my-job:
    # job name
    name: My Job
    # running env of job(Currently GitHub supports ubuntu macOS Windows)
    runs-on: ubuntu-latest
    # steps
    steps:
    # name of step 1
    - name: Checkout
    # using predefined actions from GitHub action market
      uses: actions/checkout@master
    # name of step 2
    - name: Print a greetings
    # environment variables in step 2
      env:
        MY_VAR: Hi there! My name is
        FIRST_NAME: Mona
        MIDDLE_NAME: The
        LAST_NAME: Octocat
     # executable commands in step 2
      run: |
        echo $MY_VAR $FIRST_NAME $MIDDLE_NAME $LAST_NAME.

GitHub has a Official Action Market where you can use predefined actions to simplify your work. For example, actions/setup-node represents an action from the github.com/actions/setup-node repository, which is used to install Node.js.

Different version:
actions/setup-node@74bc508 # refer to a particular commit
actions/[email protected]    # refer to a stable tag
actions/setup-node@master  # refer to a branch

The entire workflow runs on a machine hosted in GitHub (you can only execute actions but can not login). However you can set your own host server as well, see the official document for more details.

CDCF CI for Windows

name: windows compile

on: [push]

jobs:
  build:
    runs-on: windows-latest

    steps:
      - uses: actions/setup-python@v1
      - name: Install conan && conan package tools
        run: |
          python -m pip install --upgrade pip
          pip install conan==1.24.1
          pip install conan_package_tools
      - uses: actions/checkout@v1
      - name: conan
        run: |
          mkdir build && cd build
          conan remote add inexorgame "https://api.bintray.com/conan/inexorgame/inexor-conan"
          conan install .. -s build_type=Release --build missing
      - name: cmake
        env:
          ACTOR_SYS_ONLY: 1
        run: |
          cd build
          cmake .. -G "Visual Studio 16 2019" -DCMAKE_TOOLCHAIN_FILE="${env:GITHUB_WORKSPACE}\build\conan_paths.cmake"
          cmake --build . --config Release

notes:

• Windows environment uses powershell, so ${env:XXX} is the right syntax to parse env variable.
• DCMAKE_TOOLCHAIN_FILE need to specify an absolute path, and the path must be enclosed in double quotes.
• When building a Visual Studio project from the command line, the Debug Release mode is invalid when specified in cmake, but specified in make.