Run CI and deploy docs with GitHub Actions

[sethaxen]

Basically the same as JuliaDiff/ChainRules.jl#309, but with Documenter.

[sethaxen]

All x86 and/or nightly builds fail, but all 64-bit and release versions pass.

[willtebbutt]

Hmm do we want to bother running on 32bit, or is 64bit sufficient?

[sethaxen]

Hmm do we want to bother running on 32bit, or is 64bit sufficient?

64 bit is sufficient with what we were doing with Travis. However, it was recommended to test ChainRules with 32-bit, and since the test suite depends so strongly on FiniteDifferences, it would be nice to make sure that defaults, etc are good for 32-bit here.

[willtebbutt]

@sethaxen it doesn't look like we're currently running on 32bit builds, so I would suggest that we

1. open an issue about 32 bit to decide it we actually want to do it, and
2. only use 64 bit builds in this PR so that we can get CI back up and running in the mean time.

Does this sound reasonable to you?

[sethaxen]

@willtebbutt okay done!

[willtebbutt]

@oxinabox @mattBrzezinski what are your thoughts about the CI configuration? Would be good if one of you could take a look.

[mattBrzezinski]

@oxinabox @mattBrzezinski what are your thoughts about the CI configuration? Would be good if one of you could take a look.

I think this line will allow for nightly failures to not matter? (I'm not 100% familiar with GHA though)

https://github.com/JuliaCloud/AWSS3.jl/blob/master/.github/workflows/CI.yml#L14

Then we can just add the nightly to the CI.yml file, and scrape the other one. Also, would be nice to test on 1.3, I think that we use this package at Invenia. Someone correct me otherwise.

[sethaxen]

Then we can just add the nightly to the CI.yml file, and scrape the other one. Also, would be nice to test on 1.3, I think that we use this package at Invenia. Someone correct me otherwise.

Unless GitHub actions has recently changed something, when you use continue_on_error, then it marks the workflow as passing even if it failed. So if any nightly build fails, it will still get a green check mark in the PR, and you'll need to actually open the logs to find out that anything failed. But if we don't use it, then if nightly fails, the whole CI is marked as failure in the badge. So I always have a separate CI for nightly so I can see actual failures without affecting the badge.

[mattBrzezinski]

Then we can just add the nightly to the CI.yml file, and scrape the other one. Also, would be nice to test on 1.3, I think that we use this package at Invenia. Someone correct me otherwise.

Unless GitHub actions has recently changed something, when you use continue_on_error, then it marks the workflow as passing even if it failed. So if any nightly build fails, it will still get a green check mark in the PR, and you'll need to actually open the logs to find out that anything failed. But if we don't use it, then if nightly fails, the whole CI is marked as failure in the badge. So I always have a separate CI for nightly so I can see actual failures without affecting the badge.

Ah I see, different use cases I suppose. In that case, do you know if it's possible for actions to inherit from another one? I would be nice to centralize the common code from CI.yml and Nightly.yml into one file, then have each of these inherit from them.

If not possible, this LGTM.

[sethaxen]

In that case, do you know if it's possible for actions to inherit from another one? I would be nice to centralize the common code from CI.yml and Nightly.yml into one file, then have each of these inherit from them.

I don't think so. GA doesn't have support for workflow templates like e.g. Azure does.

[mattBrzezinski]

In that case, do you know if it's possible for actions to inherit from another one? I would be nice to centralize the common code from CI.yml and Nightly.yml into one file, then have each of these inherit from them.

I don't think so. GA doesn't have support for workflow templates like e.g. Azure does.

In that case, send it! (Unless Lyndon has anything to add)

[nickrobinson251]

Everything substantive looks good! But there's a small naming issue 😆 😭