Migrate from Travis to Github actions

[fao89]

Github Actions

• Current run:

python27 - static
python36 - dynamic
python37 - upgrade

https://github.com/fabricio-aguiar/ansible-pulp/runs/423332526

• Full run:

all python versions x all scenarios

https://github.com/fabricio-aguiar/ansible-pulp/actions/runs/33601847
* seems that all tests ran in parallel

Note:

some TRAVIS environment variables are hard to replace, like TRAVIS_COMMIT_RANGE
I still not found a way to get the commit range

[dralley]

@fabricio-aguiar re:

some TRAVIS environment variables are hard to replace, like TRAVIS_COMMIT_RANGE

I think there's a GITHUB_SHA environment variable. I've also seen references to github.event.head_commit.message (an intrinsic that you would need to store as an environment variable) but I can't find any documentation for the latter.

[fao89]

@fabricio-aguiar re:

You'll probably need to do something like:

- name: Store Commit SHA
 env:
    TRAVIS_COMMIT_SHA: ${{ github.sha }}

Which should give you The commit SHA that triggered the workflow run., and then grab the commit message from the command line. I'm not sure if this is the exact syntax you need though, total guess.

https://help.github.com/en/actions/automating-your-workflow-with-github-actions/contexts-and-expression-syntax-for-github-actions#github-context

edit: here's someone asking about a similar problem and some solutions: https://github.community/t5/GitHub-Actions/Accessing-commit-message-in-pull-request-event/td-p/40856

The problem is, it only gets the SHA for the last commit, I found that this would bring the SHA for the range:
github.event.commits.*.sha
but when I tested for push event it only brought the last commit also, I'm curious to see if for pull_request event it will work.
https://developer.github.com/v3/activity/events/types/#pushevent

[dralley]

@fabricio-aguiar How about we split off the "remove Travis CI" stuff into a second PR, that we can make immediately after this one? Then we can know immediately whether the Github Actions integration works for commit checks with Pull Requests, and not break Travis until we know that it does?

[dralley]

Do you think it's worthwhile to separate out the commit validation "job" from the others? Since it runs quickly and is one of the most common things to fail a PR? It also only needs to happen once (no benefit in applying it to the matrix), and if the dev notices that if failed they probably don't even need to inspect the result to realize why it failed.

[fao89]

Do you think it's worthwhile to separate out the commit validation "job" from the others? Since it runs quickly and is one of the most common things to fail a PR?

I believe so, so far what I noticed is: travis seems like monolith and gh actions seems like microservices. I believe if we migrate to gh actions, in the future we will break many things into smaller pieces of code

[fao89]

Thanks to @dralley now I have a replacement for TRAVIS_COMMIT_RANGE:
CI: https://github.com/fabricio-aguiar/revolut/runs/425544272?check_suite_focus=true#step:4:2
code: https://github.com/fabricio-aguiar/revolut/compare/test_commit_range

[mikedep333]

Other than the name of the 1 step, LGTM!

[mikedep333]

We're pulling them rather than building them.

[bmbouter]

This looks good. Let's give it a try! 🚀