wehs7661 / ensemble_md

A python package for performing GROMACS simulation ensembles
MIT License
13 stars 4 forks source link

An overview of CircleCI issues #55

Open wehs7661 opened 3 months ago

wehs7661 commented 3 months ago

Here is a list of CirclCI issues we have encountered using different settings in .circleci/config.yml.

Using the default virtual machine

This refers to the case where the config.yaml file contains a section like below:

jobs:
  test:
    machine:
      - image: default

...

Currently, the default virtual machine uses Python 3.12, which always triggers the issue mentioned in #52 when installing ensemble_md. An example failed build can be found in https://github.com/wehs7661/ensemble_md/commit/b9ba4785c1169da8c5858ede74c9f8cd7c066b60.

Using Docker images

This refers to the case where config.yaml file contains a section like below:

jobs:
  test:
    docker:
      - image: cimg/python:<<parameters.python-version>>
    parameters:
      python-version:
        type: string

...

Multiple builds based on different Python versions can be launched by the following section:

workflows:
  continuous-integration:
    jobs:
      - test:
          name: test-python-3.8
          python-version: "3.8"
      - test:
          name: test-python-3.9
          python-version: "3.9"

...

Here are issues we have seen for builds based on different versions.

Temporary workaround

These are likely issues stemming from CircleCI itself rather than our package. For now, we remove tests based on Python versions 3.8, 3.9, and 3.12 and only preserve those based on Python 3.10 and 3.11. In addition, we remove MPI tests. We will revisit these CI issues when they become a bottleneck for the development of the package. This issue will be closed if we can find a way to successfully run CI builds based on Python 3.8 to 3.12, without having any MPI test issues.

wehs7661 commented 3 months ago

Here is a copy of the content of issue #53, which as been closed as we decided to gather all CI-relevant issues here.


CircleCI builds based on Python 3.12 have been failing due to an error that seems related to some conflicts between Python 3.12 and versioneer.py, as shown below:

Processing /home/circleci/project
  Preparing metadata (setup.py) ... error
  error: subprocess-exited-with-error

  × python setup.py egg_info did not run successfully.
  │ exit code: 1
  ╰─> [18 lines of output]
      /home/circleci/project/versioneer.py:421: SyntaxWarning: invalid escape sequence '\s'
        LONG_VERSION_PY['git'] = '''
      Traceback (most recent call last):
        File "<string>", line 2, in <module>
        File "<pip-setuptools-caller>", line 34, in <module>
        File "/home/circleci/project/setup.py", line 30, in <module>
          version=versioneer.get_version(),
                  ^^^^^^^^^^^^^^^^^^^^^^^^
        File "/home/circleci/project/versioneer.py", line 1480, in get_version
          return get_versions()["version"]
                 ^^^^^^^^^^^^^^
        File "/home/circleci/project/versioneer.py", line 1412, in get_versions
          cfg = get_config_from_root(root)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "/home/circleci/project/versioneer.py", line 342, in get_config_from_root
          parser = configparser.SafeConfigParser()
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      AttributeError: module 'configparser' has no attribute 'SafeConfigParser'. Did you mean: 'RawConfigParser'?
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: metadata-generation-failed

× Encountered error while generating package metadata.
╰─> See above for output.

note: This is an issue with the package mentioned above, not pip.
hint: See above for details.

Exited with code exit status 1

An example failed build can be found for the the commit b9ba4785c1169da8c5858ede74c9f8cd7c066b60. Currently, we have left out settings for performing CI based on Python 3.12 for now, but will look into this more in the future.

wehs7661 commented 3 months ago

Also, here is a copy of issue #44


For unknown reasons, the unit tests for functions that use MPI occasionally fail with uninformative STDOUT/STDERR. Instead of figuring out the underlying reason for these failures, an easier way to ensure that at least the build on the master branch passed the CI may be simply rerunning the CI. However, this would require some modifications in config.yaml. Some instructions can be found here.