Suggested workflow for testing a build on a CI service?

[madig]

I want to install a wheel package and have the test suit run over it, like tox does. The purpose is to test that an installed package actually works.

I have a GitLab CI script like this:

build:
    stage: build
    script:
        - pip install poetry
        - poetry build
    artifacts:
        name: "${CI_PROJECT_NAME}_${CI_BUILD_REF_NAME}"
        paths:
            - dist/*.whl

test:
    stage: test
    script:
        - pip install dist/*.whl pytest ufo2ft
        - cd tests && pytest

The test stage receives dist/*.whl, which we can install. I have to manually specify the development dependencies though. Doable, but not very elegant. Is there a better workflow with poetry?

[moigagoo]

Have you considered using poetry develop and then running the tests with poetry run pytest?

[madig]

I presume that installs the package in a venv? How is it different from install? The documentation doesn't seem to mention it?

[moigagoo]

Yes it does, but install doesn't do that. install installs the dependencies, but not the package itself.

[madig]

But does it install it in a -e . way? Do I test the entire installation procedure with that?

PS: Just from looking at it, I expected install to actually install the package. Maybe call it install-dependencies instead?

[moigagoo]

But does it install it in a -e . way?

Exactly. See this issue for more information: #34

Do I test the entire installation procedure with that?

You're testing the installed package rather than the installation routine itself with that.

Maybe call it install-dependencies instead?

Hmmm, maybe poetry deps is a good alternative. @sdispater is the one to make this kind of decisions.

[madig]

You're testing the installed package rather than the installation routine itself with that.

Maybe that's good enough. My intention here is to be sure that a package actually installs and works. I got bitten by a Python2/3 Unicode issue in a setup.py once, it worked on Py2 but not on Py3 -- and there was no CI with Py3 set up to catch this before the package hit PyPI.

[moigagoo]

there was no CI with Py3

FYI Travis CI lets you pick the Python version. For example: https://github.com/moigagoo/cliar/blob/develop/.travis.yml#L2

[madig]

I know, we have since improved ;)

[madig]

Also, wouldn't this run the tests against the directory instead of the installed package:

poetry develop
poetry run pytest

?

[moigagoo]

I think this will run the tests against the directory, but with the package installed. It's just that in Python's path resolution algorithm current dir comes before other paths, so the package from the current dir will be imported before the one installed with develop.

However, should you import the package from a file that doesn't start with test_, the version installed with develop will be imported.

But it's the same version anyway, so the result will be the same. poetry develop makes the package being tested importable, that's basically all it does.

[funkyfuture]

fyi, i currently employ this snippet for the config of Travis CI:

install:
  - travis_retry pip install poetry
  - travis_retry poetry install
script:
  - poetry run make $TARGET

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

Closing this issue automatically because it has not had any activity since it has been marked as stale. If you think it is still relevant and should be addressed, feel free to open a new one.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.