Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable CI on Github #3571

Merged
merged 2 commits into from
Dec 3, 2019
Merged

Enable CI on Github #3571

merged 2 commits into from
Dec 3, 2019

Conversation

sphuber
Copy link
Contributor

@sphuber sphuber commented Nov 25, 2019

Fixes #3553

I did not touch the files for the Jenkins tests yet. I want to see what it is exactly that we want to run there and if possible simplify the scripts and remove what we no longer need. The current setup also does not include coverage yet.

To move the CI to GitHub actions, I created a workflow .github/workflows/ci.yml.
This defines 5 different actions:

  1. conda: will run .github/workflows/conda.sh to install conda and create the environment from environment.yml
  2. docs: will build the documentation
  3. pre-commit: runs pre-commit on all the files
  4. tests: runs .github/workflows/tests.sh to run all tests for both backends, for now only for python 3.7 but other versions can easily be added in the matrix. The tests include the entire unit test suite through verdi devel tests as well as the various stand alone tests in .ci
  5. verdi: tests the loading speed of verdi

The reason I put the actions in separate actions is that many of them do not require the same setup and like this they will run in parallel making the total run time shorter. I also feel that the files are clearer this way and it is easier to understand what is going on and what actions is responsible for what. The only downside of this approach is if we would run out of actions slots, but it seems there is only a limit on number of concurrent workflows, which at 20 per repository I don't think we will hit very often.

Finally, to simplify the configuration of profiles, computer and codes for the tests action, I have created .yaml configuration files in .github/config which are called in .github/workflows/setup.sh.

Copy link
Member

@ltalirz ltalirz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot @sphuber for all the work, this is great!

Since there are quite a few new files, could you perhaps describe in a few words what has changed?
That would make a detailed review a bit quicker.

@sphuber
Copy link
Contributor Author

sphuber commented Nov 25, 2019

@ltalirz just added an overview, let me know if something is still missing.

Copy link
Member

@ltalirz ltalirz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall looks good to me, some minor suggestions

.ci/test_process.py Outdated Show resolved Hide resolved
.github/config/doubler.yaml Show resolved Hide resolved
.github/workflows/conda.sh Outdated Show resolved Hide resolved
.github/workflows/ci.yml Show resolved Hide resolved
.github/workflows/tests.sh Outdated Show resolved Hide resolved
setup.json Show resolved Hide resolved
@sphuber sphuber force-pushed the fix_3553_github_ci branch 2 times, most recently from 3eb6d19 to e90914d Compare November 26, 2019 07:03
@sphuber
Copy link
Contributor Author

sphuber commented Nov 26, 2019

@ltalirz I think the current state then is ready. I will then add a commit to remove Travis and simplify the remaining code necessary to run on Jenkins

@sphuber sphuber force-pushed the fix_3553_github_ci branch 7 times, most recently from 1aa77e3 to cdef5de Compare November 26, 2019 12:12
@sphuber sphuber marked this pull request as ready for review November 26, 2019 12:46
@sphuber
Copy link
Contributor Author

sphuber commented Nov 26, 2019

This is essentially ready. Once we have released 1.0.1 and then merged PR #3566 into develop this can be rebased. We can then turn of Travis as required checks and enable the new GitHub workflow. The only remaining differences with the current situation:

  • Coverage has been removed: I vote that we try to move our unit testing to pytest soon and then use the coverage plugin. This should solve quite a few issues that are currently open related to coverage.
  • Transifex: this deploy trigger is not yet ported
  • PyPI release: this deploy trigger is also not yet ported, but I want to do this separately to make sure it works well.

Add a GitHub workflow `.github/workflows/ci.yml` that will trigger on
push and pull requests. It will run the five actions it defines:

 * `conda`: will install conda and create the environment
 * `docs`: builds the documentation with nitpick warning
 * `pre-commit`: runs pre-commit on all files
 * `tests`: runs `verdi devel tests` and the stand alone test files
 * `verdi`: runs the tests that check the load time is acceptable

All tests are performed for python 3.7 except for the `tests` action
that is done for 3.5 as well. Both python versions are run for both
database backends in a matrix strategy. Even though we support 3.6 as
well we do not explicitly test it since it will require another two
builds and testing 3.5 and 3.7 should give decent guarantees.

Finally the argument for multiple individual actions instead of joining
them is based on the fact that there does not seem to be a limit on
concurrent number of actions on GitHub as of this writing. This means
that by spreading them out, allows running them in parallel which should
reduce the overal runtime of the continuous integration workflow.
@sphuber
Copy link
Contributor Author

sphuber commented Dec 2, 2019

@ltalirz with v1.0.1 released, python 2 dropped, this PR rebased, it is now ready to go!

@sphuber sphuber requested a review from ltalirz December 2, 2019 17:02
@sphuber
Copy link
Contributor Author

sphuber commented Dec 2, 2019

The majority of tests are now run through a GitHub CI workflow. This
means it is not necessary to also run those on Jenkins, especially that
Jenkins was originally configured to just run additional tests that were
more computationally intensive. Therefore, we only keep the RPN test to
run on Jenkins for now.
@sphuber sphuber mentioned this pull request Dec 3, 2019
@CasperWA CasperWA added this to In progress in Coding Week 2019 via automation Dec 3, 2019
Copy link
Member

@ltalirz ltalirz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks @sphuber , I've gone through everything and looks good to go!

run:
.github/workflows/tests.sh

verdi:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

still seems like a bit of a waste to do all of the installation just to run one test...
anyhow, it's fine for now

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's bask in the superfluous wealth of practically unlimited parallel builds :)

@sphuber sphuber merged commit 1a1da24 into aiidateam:develop Dec 3, 2019
Coding Week 2019 automation moved this from In progress to Done Dec 3, 2019
@sphuber sphuber deleted the fix_3553_github_ci branch December 3, 2019 18:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

Run tests on python 3.7
2 participants