Make github action template

[joemarshall]

It would be great to have a github action template for this -

So in other projects to have a complete build and test one could just do something like:

    steps:
    - uses: actions/checkout@v3
    - uses: actions/setup-python@v4
      with:
        python-version: 3.10.2
    - uses: mymindstorm/setup-emsdk@v11
      with:
        version: 3.1.14
    - run: pip install pyodide-build==0.21.0
    - run: pyodide build    
    - uses: pyodide/pytest-pyodide@v1
       with:
         pyodide-versions: [0.21.0]
         browsers: [chrome,firefox]
         os: [linux,macos]
         test-folder: tests

It would save duplicated complexity in other projects (check out the CI actions in this repo, and the similar stuff in micropip for example)

[joemarshall]

Even crazier would be to make a further action in pyodide-build, so you could just do a pyodide build of a package and test it in CI automatically. So adding a pyodide build and test to CI for a package would in theory be as simple as this:

- uses:  pyodide/pyodide-build@v1
  with:
    pyodide-versions:[0.21.0]
    test-browsers: []
    test-os: []
    test-folder:tests
    artifact-name: my lovely pyodide wheel

[rth]

Yes, agreed. I also realized that setting this up for many repos manually was fairly time consuming.

I would be +1 for a GH actions setup to do it would certainly make this simpler. Though pyodide-build is a slightly different use case I think (as typically one builds packages once, then tests for different browsers). So maybe two separate actions would be better (of indeed some way of parametrizing them). We need to read https://docs.github.com/en/actions/creating-actions on the best way of doing this. Also @ryanking13 might be interested.

BTW, @joemarshall are you interested in an invite to the "Community Members" team in the Pyodide org? I sent you an email about it in 2021, but maybe it got lost :) It does not give any specific write permissions (short of issue triage on the Pyodide repo) and mostly aims to recognize your contribution to the project these years. Thanks again for that!

[jobovy]

A while back I create a version of a pyodide-build action, which is now obsolete because of the new out-of-tree build mechanism: https://github.com/jobovy/pyodide-buildpackage-action. But at it's core, that action was a simple composite action combining the necessary steps to build pyodide packages in-tree. So it shows how easy it is to create a composite action along the lines suggested here (I think all you need is a action.yml file like https://github.com/jobovy/pyodide-buildpackage-action/blob/main/action.yml).

I would prefer having separate build and test actions. For example, to build galpy, I can't use the standard current pyodide-build action because I need to compile the GSL first (between setting up the emsdk and running pyodide-build. But it could still be useful to use the standard test action after the non-standard build. Even though the steps to build a package aren't complicated, it would still be useful to have an action so users don't have manually keep the python/emscripten/pyodide versions in sync.

[ryanking13]

+1 for having separate build and test actions. I think we can start with making GHA template for pytest-pyodide.
About pyodide-build actions, I'm not sure about making GHA template for it until we can say that it is in a stable state.

[joemarshall]

Thinking about this, whilst I showed it with a list of versions and browsers, it would probably make sense to make the pytest-pyodide action take a single browser/os/pyodide version, and then people can use matrices in GitHub actions to run the different variations. That way it would run tests in parallel nicely.

@rth totally missed that email, yes please!

[joemarshall]

I've messed around with it, and it really needs to be a reusable workflow (which comes as a whole job) not an action, unless someone is going to maintain a separate set of docker images for testing which would be a pain.

I've prototyped something here, you pass in the workflow artifact from your build (e.g. the build wheel) as a dependency, and it runs pytest using the same matrix as used for testing pytest-pyodide itself. In fact, in my fork, pytest-pyodide itself tests using the same reusable workflow.

Here it is doing pytest-pyodide testing
https://github.com/joemarshall/pytest-pyodide/actions/runs/3213315950

Here is what it looks like in a sub-project (and you can see how the actions fit together in that subproject to build and test a wheel)
https://github.com/joemarshall/pytest-test-pyodide-test/actions/runs/3213349267

[rth]

Done in https://github.com/pyodide/pyodide-actions but please comment if you think it's not sufficient.