Moved to  GitHub: automate Raspberry Pico project build verification with GitHub Actions 

You can Make GitHub build your project. I'm using an Action to check out branches and build them, when a pull request is submitted.
I adapted an existing flow from the Raspberry organisation. Here's what it does

• check out the branch that's the source for the pull request
• check out Pico-SDK, the current development branch
• install CMake
• install the arm bare metal GNU toolchain
• build the SDK
• build the project
• react on pull request creation on the main and develop branch.
• make successful compilation a mandatory check for the pull request.

If the build fails, the pull request fails. That's what I try to achieve in this exercise:

• developers can check in non-working in feature branches.
• once ready to ask merging with one of the two protected branches (develop or main), code should meet quality requirements and should build.
  That's the moment that you deem your work done, and should be ready for a code review.
  If your code breaks the build at this point, you impact others - and maybe the production release. It's a fail.
• Code reviewers don't have to spend time validating non-funcioning code.

The script I'm using is based on the Raspberrry MacOS build for Pico. I adapted it for Linux.

Script source of build.yml:

name: Build on ubuntu against pico-sdk develop
on:
  workflow_dispatch:
  #push:
  #  branches:
  #    - 'develop'
  #    - 'main'
  pull_request:
    types: [opened, reopened]
    branches:
      - 'develop'
      - 'main'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    
      - name: Clean workspace
        run: |
          echo "Cleaning up previous run"
          rm -rf "${{ github.workspace }}"
          mkdir -p "${{ github.workspace }}"
      - name: Checkout pico_gps_teseo_i2c
        uses: actions/checkout@v4
        with:
          path: pico_gps_teseo_i2c

      - name: Checkout pico-sdk/develop
        uses: actions/checkout@v4
        with:
          repository: raspberrypi/pico-sdk
          ref: develop
          path: pico-sdk

      - name: Checkout pico-sdk submodules
      
        working-directory: ${{github.workspace}}/pico-sdk
        run: git submodule update --init
      - name: Install dependencies
        run: |
          sudo apt-get install cmake
          #curl -Lo gcc-arm-none-eabi.tar.bz2 "https://developer.arm.com/-/media/Files/downloads/gnu-rm/10.3-2021.10/gcc-arm-none-eabi-10.3-2021.10-x86_64-linux.tar.bz2?rev=78196d3461ba4c9089a67b5f33edf82a&hash=5631ACEF1F8F237389F14B41566964EC"
          #sudo mkdir /opt/gcc-arm-none-eabi
          #sudo tar xf gcc-arm-none-eabi.tar.bz2 --strip-components=1 -C /opt/gcc-arm-none-eabi
          #echo 'export PATH=$PATH:/opt/gcc-arm-none-eabi/bin' | sudo tee -a /etc/profile.d/gcc-arm-none-eabi.sh
          #export PATH=$PATH:/opt/gcc-arm-none-eabi/bin
          #export PICO_TOOLCHAIN_PATH=/opt/gcc-arm-none-eabi/bin
          #source /etc/profile
          #arm-none-eabi-gcc --version
          sudo apt install gcc-arm-none-eabi
          
      - name: Build Project

Excuses for the formatting. The code editor does not want to accept this code. Click on this link for a better view.

When you create this script in the .github/workflows folder, it 'll kick off each time a pull rrequest is opened for main or develop. But it will not impact the pull request.
If you want to make pull requests dependent on successful build, you 'll also hav to create a ruleset for the branch.

On your repository's web page on GitHub, select settings -> Rules -> Rulesets.
If the branch(es) you want to protect don't have a ruleset yet, create one. Else you can update the existing one.

The first checkbox will take care that the branches you want to protect, can only accept commits via a pull request. When you work together as a team, it's good that branch owners can check code before it's merged in the code base.
The second check also adds the condition, that the build job must complete in good order.

A developer that submits a pull request, gets this page:

They don't have to wait for this to complete. They 'd get an email if it failed. Once the job is completed, the reviewer sees the screen capture I posted at the start of this blog. If the job was successful, code review and merge can happen.

How does it fit in my workflow:

I created another action earlier:  GitHub: automate project documentation with DoxyGen, and publish online after pushing commits . Together, the 2 automate a decent part of code management:

• the build validation described here, when a pull request is made to development or main
• when a pull request to main is accepted and merged by the branch manager (me :) ), the doucmentation is regenerated and published to github.io.

Future improvements:

I'm considering to let the job create a project release, when a new Version TAG is created in the repository. I'd have to make these changes:

• add trigger on TAG creation event. Filter on tags that start with 'v'.
• change the build type from Debug to Release
• use a GitHub Action to create a release in the repository, and upload the .uf2 file as asset to that release.

Link to all posts.