Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Code Reviews

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Comments on Github workflow for a C application

Parent

Github workflow for a C application

+5
−0

This is my first try at automating building and testing some C code for these platforms:

  • Linux
  • Windows
  • MacOS
  • OpenBSD (arm64 and x86-64)
  • FreeBSD (arm64 and x86-64)
  • NetBSD
  • Oracle Solaris
  • OmniOS

It just builds and runs the tests with make:

name: Arena Tests

on: [workflow_dispatch, push, pull_request]

jobs:
  test_linux:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Build and Test
        run: make test


  test_macos:
    runs-on: macos-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Build and Test
        run: make test


  test_bsd:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        os:
          - { name: freebsd, architecture: x86-64, version: '14.0' }
          - { name: freebsd, architecture: arm64, version: '14.0' }
          - { name: openbsd, architecture: x86-64, version: '7.4' }
          - { name: openbsd, architecture: arm64, version: '7.4' }
          - { name: netbsd, architecture: x86-64, version: '9.3' }

    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Build and Test 
        uses: cross-platform-actions/action@v0.24.0
        with:
          operating_system: ${{ matrix.os.name }}
          architecture: ${{ matrix.os.architecture }}
          version: ${{ matrix.os.version }}
          run: make test
            

  test_solaris:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Build and Test
        uses: vmactions/solaris-vm@v1
        with:
          run: |
            sudo pkg install developer/gcc/gcc-c-7
            sudo ln -s /usr/bin/gcc /usr/bin/cc
            make test


  test_omnios:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Build and Test
        uses: vmactions/omnios-vm@v1
        with:
          run: |
            sudo pkg install build-essential
            make test


  test_windows:
    runs-on: windows-latest

    defaults:
      run:
        shell: msys2 {0}

    steps:
      - name: Setup MSYS2
        uses: msys2/setup-msys2/@v2
        with:
          update: true
          install: >-
            git
            make
            gcc
      - name: Checkout
        uses: actions/checkout@v4
      - name: Build and Test
        run: make test

Review Request:

Anything, everything. Any simplifications I can make? I also see a lot of duplication in the file.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

0 comment threads

Post
+0
−0

I don't see much duplication in your workflow file here.

Is there a lot of boilerplate? Yes, but I believe that's expected for CI/CD workflow definitions and a result of using the workflow being declaratively defined.

One small nitpick would be to create a custom container image for all the jobs that run on Ubuntu (ie. test_solaris, test_omnios, test_linux). You could install any additional software into this container image to save yourself additional runtime wasted on the package installations.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.

1 comment thread

I wouldn't say that "a lot of boilerplate" is a consequence of a declarative definition. It's a conse... (2 comments)
I wouldn't say that "a lot of boilerplate" is a consequence of a declarative definition. It's a conse...
Derek Elkins‭ wrote 5 months ago

I wouldn't say that "a lot of boilerplate" is a consequence of a declarative definition. It's a consequence of configuration languages often being extremely weak with little to no abstraction facilities. Often this is resolved by using full-blown programming languages, but those have many downsides when used as configuration languages. A configuration language trying to be the best of both worlds is Dhall (which can output YAML among many other non-programmatic configuration formats). Dhall can easily capture the redundant patterns in this example, while also guaranteeing that you would get the same result in any environment with no potential for additional side-effects.

zmzaps‭ wrote 4 months ago

Good point! Declarative languages often are weak, but certainly don't have to be. I'll have to give Dhall a look.