switch to checkout@v2 with submodules and fetch-depth 0

[jepler]

This switches us to the current version of checkout, which has recently added support for a feature we use (submodules). This feature was in v1 but was not initially in v2. It was recently added to v2.

For more background, see actions/checkout#176 and #2718.

Things to check: that the checkout includes the needed tags that fetch-depth 0 is intended to add.

Besides just keeping modern, it appears to be the case that checkout@v2 works properly when re-running a failed actions job.

[tannewt]

Looks like builds with frozen modules are failing. You'll want to use git submodule to fetch tags within them as well.

[jepler]

I think this is correct now, but frustratingly some of the builds spent the night in the "queued" state so we don't have green from CI yet. @dhalbert what would you like me to do?

[dhalbert]

@jepler I canceled the job and expected to find a "re-run jobs" button, but there isn't one ☹️ . Is there a minor change you can push to see if we can restart things? But if there's not going to be a "restart jobs" button, I'm worried about merging this in yet. Try another push and let's see what happens. We should have at least one perfect build before merging. Perhaps we should open an issue about this in https://github.com/actions/checkout/issues. And let's monitor the other issues in that repo. We don't want to end up worse off than before.

[jepler]

I think that may just be the usual github flakiness about cancel jobs, since the ones that never started were still in "waiting to start" state. I pushed an update, let's see how it goes.

[jepler]

The previous run completed, and a re-run jobs button was presented. I've clicked it, and it appears the new checks have started.

[jepler]

On the re-run there were some spurious failures. I looked at two, and they were the same. When fetching tags inside submodules, it failed (possibly on the first one?) insisting that there is no "origin" remote.

2020-03-24T18:41:57.1329727Z ##[group]Run git submodule foreach git fetch --recurse-submodules=no origin +refs/tags/*:refs/tags/*
2020-03-24T18:41:57.1329968Z �[36;1mgit submodule foreach git fetch --recurse-submodules=no origin +refs/tags/*:refs/tags/*�[0m
2020-03-24T18:41:57.1368812Z shell: /bin/bash -e {0}
2020-03-24T18:41:57.1368918Z env:
2020-03-24T18:41:57.1369019Z   pythonLocation: /opt/hostedtoolcache/Python/3.5.9/x64
2020-03-24T18:41:57.1369124Z ##[endgroup]
2020-03-24T18:41:57.1993963Z Entering 'extmod/ulab'
2020-03-24T18:41:57.2031660Z fatal: 'origin' does not appear to be a git repository
2020-03-24T18:41:57.2040235Z fatal: Could not read from remote repository.
2020-03-24T18:41:57.2040559Z 
2020-03-24T18:41:57.2040983Z Please make sure you have the correct access rights
2020-03-24T18:41:57.2041212Z and the repository exists.
2020-03-24T18:41:57.2041998Z fatal: run_command returned non-zero status for extmod/ulab
2020-03-24T18:41:57.2042265Z .
2020-03-24T18:41:57.2046336Z ##[error]Process completed with exit code 128.

Earlier in the log, nothing seemed out of the ordinary when cloning ulab:

2020-03-24T18:35:48.2648680Z Submodule path 'extmod/ulab': checked out 'a91b36986d81fd906a6232010778f2a93d690f8e'

[jepler]

I feel like this isn't going to work out right now. Someone else is welcome to take up the mantle.