Github Actions

This project is automatically processed using Github Action which allows building continuous integration and continuous deployment pipelines for testing, releasing and deploying software without the use of third-party websites/platforms.

Currently, we have developed the next procedures for this project:

Pull Request

  • Python Code format check: Python code format is checked in every pull request following Pep8 standard (Level 2 aggressive) and isort to sort imports. If format is incorrect, a bot will comment in pull request advising that issue and notifying it will be correct merging with main.

  • Code type check: We are using pytype in Sinergym module. This let dynamic types in Python like it is usual, but controlling input and output types in functions and methods. This workflow ignore import-error type using command pytype -d import-error sinergym/. For example, pytype cannot include google cloud storage module, so this option specification is necessary. If some type error happens, the workflow show error until user fix it.

  • Documentation Checks: This action checks whether source documentation has been modified in every pull-request. If source documentation has been updated, it will compile documentation with Sphinx and raise errors if exist. This workflow checks vocabulary spelling too. If you have a mistake and sphinx finds a unknown word, this workflow will return an error. Writing documentation about this topic is very possible that you want to use a word that is not in default dictionary. In that case, you have to add that word to docs/source/spelling_wordlist.txt (please, respect alphabetical order) and Sphinx-spelling will accept words allocated in the list.

Warning

Sphinx Warning messages behave like errors for workflow status.

Note

Sphinx Spelling works on code docstring too.

  • Testing: There is another action which builds a remote container using Dockerfile and executes Pytest inner.

  • Repository security: There is a workflow which compare differences in workflows and tests from source to base. It execute that functionality only in forked repositories in order to prevent malicious software in workflow or ignore tests. Event is pull_request_target, this means workflow is checkout from base repository (our main branch) and it cannot be manipulate by third-parties.

Note

These checks can be skipped in a specific commit writing [ci skip] string in commit message. For more information, see issue #161.

Push main (or merge a pull request)

This workflows will be executed in sequential order:

  • Apply format: A bot generates a commit in main branch applying format changes when it is necessary (autopep8 2 level aggressive and/or isort module).

  • Update Documentation build to GitHub pages: A bot generates a commit in main branch applying new documentation build when it is necessary (spelling check included here too) in a folder called docs/compilation. Repository ignore default folder name build in order to compile locally to check changes.

  • Update our Docker Hub repository: This job builds container with all extra requires and it is pushed to our Docker Hub repository using latest tag automatically. It needs format and documentation jobs finish for possible changes.

New release created or modified

  • When a release is published or edited manually in the repository, there is an action which catches release tag version and uses it to build a container and upload/update on Docker Hub with that tag version.

  • At the same time, another job will update the PyPi Sinergym repository with its current version tag.

Note

See .github/workflows YML files to see code used.

Note

Whether you have a forked repository from Sinergym, we recommend you to enable Github Action in your project in order to take advantage of this functionality in your developments.

Note

Currently, the workflows explained above upload two containers. A container with all extra packages and a container with minimal installation.