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.

Sign up for GitHub

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

Jump to bottom

Standardize development dependencies / refactor GHA workflow #153

Merged
merged 6 commits into from
Jun 18, 2024
Merged

Standardize development dependencies / refactor GHA workflow #153

merged 6 commits into from
Jun 18, 2024

Commits on May 21, 2024

  1. Standardize development dependencies 

    There seems to be a preference towards using `requirements-dev.txt` vs. a `dev` extra for development dependencies, but right now neither `pip install -r requirements-dev.txt` nor `pip install -e ".[dev]" is enough to install all development dependencies.

I’ve added any dependencies listed in the `dev` extra to `requirements-dev.txt` and removed the `dev` extra so that we only have one list of dev dependencies to maintain.

This also pins the `moto` package (used to mock S3 in tests) to version 4.x as version 5 release a few days ago contains breaking changes.
    @tillprochaska
    tillprochaska committed May 21, 2024
    Configuration menu
    Copy the full SHA
    223b47c View commit details
    Browse the repository at this point in the history

  2. Remove unnecessary setup in GitHub Actions workflow 

    This seems to be left over from when we still used to run tests directly in GHA runners.
    @tillprochaska
    tillprochaska committed May 21, 2024
    Configuration menu
    Copy the full SHA
    3bb18df View commit details
    Browse the repository at this point in the history

  3. Install servicelayer before running tests 

    Tests in `test_extensions.py` rely on `servicelayer` being installed as they ultimately read information from the egg info that is created during installation.

This is basically equivalent to the previous setup which executed `pip install -e .` outside of the container. As the entire directory is mounted into the container, the egg info subsequently was also available inside of the container. While that worked I found the fact that installing something outside of the container could make the tests fail or pass quite confusing. This should be a little more explicit.
    @tillprochaska
    tillprochaska committed May 21, 2024
    Configuration menu
    Copy the full SHA
    7ef6a8a View commit details
    Browse the repository at this point in the history

  4. Run everything inside of the docker container 

    Running some steps outside and some inside of the container leads to weird behavior, e.g. when file permissions/owners do not match across steps.
    @tillprochaska
    tillprochaska committed May 21, 2024
    Configuration menu
    Copy the full SHA
    477f50b View commit details
    Browse the repository at this point in the history

  5. Slim down Docker image 

    This uses a pre-built Python image based on Debian as this should be much faster than building a custom image on top of a full-feature Ubuntu.
    @tillprochaska
    tillprochaska committed May 21, 2024
    Configuration menu
    Copy the full SHA
    c935c47 View commit details
    Browse the repository at this point in the history

  6. Add separate Makefile target to run tests without starting a Docker c… 

    …ontainer
    @tillprochaska
    tillprochaska committed May 21, 2024
    Configuration menu
    Copy the full SHA
    41b2c0e View commit details
    Browse the repository at this point in the history