Automatic updating ideas

[henryiii]

I'd like to propose we add a Javascript action file for cibuildwheel. It would look like this:

- uses: joerick/[email protected]
  with:
    args: .

Maybe we could come up with some useful features here (at at least it does combine the download and run step), but there's one very useful feature this alone gives us - dependabot support! You can setup GitHub's dependabot to update your actions files once a day, a week, or a month, and it makes a PR whenever actions update. See scikit-hep/boost-histogram#466.

It does support Python as well, but I don't know a way to get it to look into an action file for pip install cibuildwheel==X and update X.

I've seen a lot of old pinned versions of cibuildwheel around when looking at projects, this would give a way for them to opt in to automatic updates in a controlled (PR) fashion.

Thoughts? Any reason this might not work?

[YannickJadoul]

I think it would be a nice feature, yes! Even if it would just nicely integrate into GHA, then (even though pip install and cibuildwheel is reasonably compact as well). Any idea how much code/maintenance this would be?

Also, does it need to be a JS action; it can't just be a "composite run steps action"? (I'm guessing the dependabot won't work then? But no experience, so just checking to be explicit, here.)

Maybe we could come up with some useful features here

Adding options, instead of stuffing them into environment variables, maybe?

- uses: joerick/[email protected]
  with:
    args: .
    options:
      CIBW_SKIP: cp27-*
      # Etc

Not sure if that now makes it so much cleaner than just an extra step to set the environment variables, though...

[joerick]

But on the upside, you could even force a specific commit hash

It think ${{ github.action_path }} expands to a filesystem path to this action's code, so the version is already specified in the uses: option - that version tag specifies which commit to get the action code from.

[henryiii]

The run is happening here: scikit-hep/boost-histogram#488 - So far, looks good! Nesting output is working. Passing in the env is working. I'd say that's a win!

[henryiii]

Yes, it should get all the code (I think), so I think ${{ github.action_path }} would work. I meant you could do uses: joerick/cibuildwheel@<hash>, which otherwise would not have worked to get a specific commit.

[henryiii]

And it's working, PR here: #494

[YannickJadoul]

Wow. I'm very impressed by speed at which you managed this, @henryiii! :-D

[Czaki]

Maybe also provide Azure Pipelines Template https://docs.microsoft.com/en-us/azure/devops/pipelines/process/templates?view=azure-devops

Github actions still do not provide an option for restart a single job (for example after network faliture)

[henryiii]

I proposed a couple of other ideas below for how to update in general, either in addition to or in replacement of the original idea.

[henryiii]

Idea 2: we could add a pre-commit action instead. This would look like:

repos:
- repo: https://github.com/joerick/cibuildwheel
  rev: v1.7.1
  hooks:
  - id: cibuildwheel
    files: .github/workflows/myaction.yml

The action would search and replace for cibuildwheel\w*==\w*\d\.\d.\d with the current version. Then you would update with pre-commit autoupdate and rerun, or you'd use pre-commit.ci to automatically make update PRs (I think it's every Sunday?).

A little more "hacky", but would work with all CIs, and we could have reasonable defaults for the files so that most common CI files would be picked up.

[henryiii]

Here's an example of the pre-commit.ci autoupdate, which happens weekly if there's an update: scikit-hep/particle#283

[Czaki]

I also try it, but the weakness of this solution is that you cannot configure the target branch for PR. I Prefer to do PR do develop, not master.
4DNucleome/PartSeg#161

But looks really nice.

[henryiii]

I think it targets the current default branch or PRs only, yes. More configuration options (vs the current absolutely no options at all) might be introduced in the future, perhaps?

[henryiii]

Personally I always make the main development branch the GitHub default. Someone visiting GitHub should see the development state and not a stale master, and that way there is no confusion when making PRs. You can still leave the stable/master/main branch as the one for read the docs and such.

[Czaki]

Maybe it is a good idea to switch the default branch to develop.

[henryiii]

Idea 3: we could write an update workflow example similar to #490 that users could add that would run on some frequency. This would be the least elegant but most flexible (and no change to cibuildwheel other than adding an example).

[YannickJadoul]

This would be CI-specific again, though?

[henryiii]

No, while the CI running it would be GHA, the wheel build can be anything. That's what I mean by CI specific. If you host on GitLab, you'd have to come up with a new example written in GitLab. But otherwise you can pretty much always add a GHA workflow file.

[mayeut]

If we're only talking about pinning/updating cibuildwheel, why not reuse what already exists for the python ecosystem. I've been using pyupbot/dependabot for quite some time now in order to update cibuildwheel (not only).
I'm using a requirements-cibuildwheel.txt dedicated to cibuildwheel as its name implies but should also work with a constraints.txt file.

      - name: Install cibuildwheel
        run: python -m pip install -r requirements-cibuildwheel.txt

I just received an update for cibuildwheel 1.7.2: mayeut/pybase64#221

[henryiii]

It's not unreasonable, but I try to avoid X.txt files for Python dependencies, and use extras (or poetry for pure-Python) only. requirements.txt tends to indicate that you can run a project without installing it, which is just asking for bugs (can link to some if you want!). I don't like opening a requirements.txt from a setup.py either! It also keeps the directory clean. Also, very few people are using this for cibuildwheel - probably because it's not in the examples - and it's kind of hard/ugly to put in an example. Sticking a single file in an X.txt file seems a little odd, too. But yes, as long as it picks up the file (I don't know what the filename support is since I haven't used it much), that's not unreasonable, especially as a way to update without a GHA.

[YannickJadoul]

I do like the idea of adding this to the examples as a way to keep cibuildwheel up to date, though.
It doesn't undo the value of #494, but it does seem to be cleaner than "idea 2" for a cross-CI approach?

[henryiii]

I think I would recommend a little section on updating - I've seen this for a GitHub action before (if I remember which one, I'll link here - but I think it was one I don't use). GitHub Actions + this method might be best as the list - pre-commit and manual bots might be too much. If someone uses Azure/other, they can use this method (which is not bad).

[henryiii]

@joerick this is what the dependabot update looks like, notice the changelog:

[joerick]

Hmm, I don't suppose there's much we can do about this except open an issue in the dependabot tracker. I notice that there are a few such issues, like dependabot/dependabot-core#2773

[joerick]

Weird that it doesn't pull a changelog from GitHub Releases

[henryiii]

@joerick Should we "publish" our action in the GitHub marketplace? I see "Publish this Action to Marketplace
Make your Action discoverable on GitHub Marketplace and in GitHub search." at the top of the main page.

[joerick]

I considered this, as it might have been neat to be discoverable in the Github Marketplace too, but I realised publishing also adds this banner to the top of your project page:

Which makes it seem like it's 'just' a Github Action, whereas we support many more CIs than that. I don't know, felt a bit 'icky' to be pushing GHA so hard?

[henryiii]

I don't think it's that bad; we show the non-action form in the readme below; and this is GitHub - it makes sense GitHub would integrate a banner for the GitHub Action. GitHub Actions, according to GitHub, has become the #⁠1 CI on GitHub. Even looking at our own listing, GHA seems to be the most popular. But totally fine if you don't want to, too - I could see this making some new visitors thinking it's only an action, not realizing it's a Python package with broad CI support, or making GHA seem to be the "recommended" solution; when really it's just the most popular. Though because it's the most popular, it has the best support from us, I think - we don't check alternative archs on any other platform, do we? (Azure wouldn't really count ;) ).