Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

guidance: how to matrixify platform builds? #7

Open
schmonz opened this issue Jan 26, 2024 · 4 comments
Open

guidance: how to matrixify platform builds? #7

schmonz opened this issue Jan 26, 2024 · 4 comments

Comments

@schmonz
Copy link

schmonz commented Jan 26, 2024

[not NetBSD-specific, arbitrarily filing this here because I just filed some other ones here]

As a pkgsrc developer, I'm trying to define a concise-enough workflow to iterate over many Unix platforms, bootstrap the pkgsrc tools, and build the packages I maintain.

For the moment, while I'm figuring out what works, I have just two jobs: one for FreeBSD and one for NetBSD. I noticed the run: command sequence was long and duplicative, so I extracted it to a shell script, which has helped. But I still have a bunch of identical copy-pasted steps before and after the vmactions one.

Before I expand coverage, I'm hoping to express platform-specific details briefly and declaratively. I think I'm wishing for something like this:

jobs:
  all-available-vmactions:
    name: >
      ${{ matrix.os.uname }}
      ${{ matrix.os.arch }}
      ${{ matrix.os.version }}
    runs-on: ${{ matrix.os.host }}
    strategy:
      matrix:
        os:
          - uname: NetBSD
            lname: netbsd
            arch: amd64
            version: '9.3'
            host: ubuntu-latest
            vmaction: vmactions/netbsd-vm@v1
            prep: |
              set -e
              /usr/sbin/pkg_add git-base
    steps:
    [...checkout, restore cache, etc....]
    - name: Platform Matrix Build
      uses: ${{ matrix.os.vmaction }}
      with:
        release: ${{ matrix.os.version }}
        prepare: |
          ${{ matrix.os.prep }}
        run: |
          ${{ matrix.os.run }}
    [...save cache, publish all artifacts, etc....]

Everything about this works except that GitHub seemingly can't perform variable substitution on the uses: step. Grrrr.

Have you found or heard about a way to accomplish the goal of iterating over every vmactions platform in a concise way? I don't want to be asking you to rearchitect your entire offering here as one Action just to work around this limitation of GitHub!

@schmonz
Copy link
Author

schmonz commented Jan 26, 2024

I found a trick! It's not perfect, but it's working. The trick:

  - steps:
    - name: Platform Matrix Build
      uses: jenseng/dynamic-uses@v1
      with:
        uses: ${{ matrix.os.vmaction }}
        with: |
          {
            "release": "${{ matrix.os.version }}",
            "prepare": "${{ matrix.os.prep }}",
            "run": "${{ matrix.os.run }}"
          }

The contents of prepare: and run: now have to be one-line JSON strings, which is a little unpleasant (starting with needing to separate shell commands with semicolons instead of newlines, and probably also making quoting less obvious). And that exerts a little extra pressure to extract command sequences of any significant length to external shell scripts, as I had already done. But it does work.

@Neilpang
Copy link
Member

glad to know you have found a solution.
It's not hard to develop another all-in-one-vm, it could just git clone the current netbsd-vm(or others), and run node index.js.

but the prepare and run for each vm are different, I don't think there is much benefit to make it all-in-one.

@schmonz
Copy link
Author

schmonz commented Jan 27, 2024

In my particular case, the run is identical across all platforms. But prepare is different for each of my VMs. For most use cases run probably would be, too. And iterating over distinct values is a typical use case for matrix builds, so I might not be the only one to benefit if you decide to invest in this direction. :-)

@Neilpang
Copy link
Member

let's keep this issue open to see if there will be enough demands.
For most cases, user wants to debug/test the vm one by one. because the bugs and solutions may vary for different vms.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants