Enable CI via GH actions

[awvwgk]

• Python 3.5 / 3.6 using preinstalled Python versions on runner
• Python 3.7 to 3.10 using conda-forge Python

TODO

• coverage upload to coveralls
• pypi upload (different workflow?)

Closes #128

[gnikit]

I would do codecov.io instead of coveralls and for PyPi we can copy this https://github.com/gnikit/fortls/blob/master/.github/workflows/python-publish.yml but we will have to get @pseewald to upload the tokens as secrets to the repo.

[gnikit]

Also, we might want to consider first swapping to setup.cfg, pyproject.toml, setup.py 3-file stubs and reshaping the testing (not in this PR though)

[awvwgk]

I would do codecov.io instead of coveralls

It looks like this project originally used coveralls, I would be fine with switching to codecov as well. @pseewald any preference?

Also, we might want to consider first swapping to setup.cfg, pyproject.toml, setup.py 3-file stubs and reshaping the testing

Let's get the CI running first before we start changing things.

[gnikit]

We might have to go and fetch the test data from the outside repos manually from the git history. I can't find all the tarball archives cp2k, cron, FLAP, rosseta, etc. Sorry my bad, I was looking at the wrong place.

We don't have to fetch the tarballs, we can just clone I recon.

[awvwgk]

We might have to go and fetch the test data from the outside repos manually from the git history. I can't find all the tarball archives cp2k, cron, FLAP, rosseta, etc.

They are fetched via git-archive tarballs from the fprettify-test branch in @pseewald's forks of the respective projects.

[gnikit]

Looks good, we need to upload the Secrets but that is only relevant for Publishing

[gnikit]

@pseewald If you can generate the tokens from PyPi Test and PyPi and store them as secrets with the name TEST_PYPI_API_TOKEN and PYPI_API_TOKEN, then this action can be used for publishing i.e. no need to use twine

[pseewald]

I'm not familiar with that process. Alternatively, we move fprettify soon to @fortran-lang, then you can take care of this as well (if you agree)?

[gnikit]

This is just a nice way to publish and upload packages to PyPi via the GitHub UI. It calls twine in the background so it needs a valid PyPi token to successfully upload the package to pseewald

This is a similar example to how the Language Server does it: https://github.com/gnikit/fortls/blob/25b793c224ce888aa533928e75386fba565d4942/.github/workflows/python-publish.yml#L34-L46

I am happy for fprettify to move to fortran-lang. Still in that case the publishing issue would persist. You would have to add the Fortran-lang PyPi account as a maintainer or owner to be able to publish the package on PyPi.

[pseewald]

@awvwgk @gnikit Thanks a lot of taking care of this, great work! Sorry for replying late.

I would be fine with switching to codecov as well. @pseewald any preference?

I have no preference due to lack of experience regarding these tools, please use whatever you prefer.

We might have to go and fetch the test data from the outside repos manually from the git history. I can't find all the tarball archives cp2k, cron, FLAP, rosseta, etc.

Sorry for this cumbersome mechanism, I'll soon make a pr for #140 where I change the way external Fortran code is added for tests. I also suggest that we use the official repositories instead of custom forks (I'll also take care of this in #140).

[gnikit]

Sorry for this cumbersome mechanism, I'll soon make a pr for #140 where I change the way external Fortran code is added for tests. I also suggest that we use the official repositories instead of custom forks (I'll also take care of this in #140).

Thanks for taking care of this @pseewald, that's great!