Define GitHub Actions CI

[Sinclert]

Continuing with issue #8, I would also suggest to create a very basic GitHub Actions CI workflow, given that there are some nice tests already defined.

The ci.yml may look something like:

name: Continuous Integration

on:
  push:
    branches:
      - master

jobs:

  test:
    needs: []
    runs-on: ubuntu-latest
    steps:
    - name: "Set up GitHub Actions"
      uses: actions/checkout@v2
    - name: "Set up Python 3.6"
      uses: actions/setup-python@v1
      with:
        python-version: 3.6
    - name: "Install Python dependencies"
      run: |
        pip install -r requirements.txt
    - name: "Test with pytest"
      run: |
        cd testsuite && pytest

[GraemeWatt]

We've been using Travis CI since the start of the HEPData project for all repositories, see https://travis-ci.org/HEPData. There's a similar .travis.yml file in each repository to run automated tests, including for the hepdata-validator. I created an issue HEPData/hepdata#157 last November to investigate the use of GitHub Actions as an alternative to Travis CI. But given that the automated tests run quite nicely on Travis CI, I don't see a strong incentive to move to GitHub Actions at the present time. Are there any major advantages? Please feel free to work on a GitHub Actions CI workflow if you think it's worthwhile.

[Sinclert]

I see some advantages of switching to GitHub Actions:

1. Clearer flow: when I look at the .travis.yml, I see steps like before_script or install...
   It is not clear for someone new to this tool, which step comes before the other. On the other hand, GitHub Actions is very easy to follow: just read top to bottom 😄
2. Support for other integrations: GitHub Actions have other integrations other than CI / CD steps. There is a marketplace of actions, with integrations like email-notifications, code-quality...
   All in one place! 🎉
3. Native: This is not an advantage per se, but usually native solutions work smoother than third party providers. Just something to consider.

It also has the following disadvantages:

1. Lack of global view: I see that on the HEP-Data profile in TravisCI one can look at all the pipelines, from all the repos, at a single look. That is something that GitHub Actions does not allow.

I understand that right now, there is a "HEP-Data" account on TravisCI, where all the pipelines run, so the decision to switch should be made organization wide.

Feel free to close this issue. The points made here could be save for a future discussion though.

[GraemeWatt]

Thanks for the comments, @Sinclert. It would be a big task to switch to GitHub Actions for all @HEPData repositories, and it's not something we want to do at the present time. @alisonrclarke has recently spent a lot of time getting Selenium end-to-end tests working on Travis CI via SauceLabs for the HEPData/hepdata repository and we don't want to repeat that work for GitHub Actions now. I'll leave this issue open, as we probably will want to use GitHub Actions eventually.