ci: fix broken CI pipeline

[JaeAeich]

Summary by Sourcery

Update Docker Compose command, pin pip version to <24.1, and add type hints.

Build:

• Pin pip version to <24.1 in the build process.

Pinning pip version because of dependency resolution issues in CI, since sooner or later this will be revisited and updated with pyproject, that will eventually update all the deps.

Chores:

• Update the Docker Compose command to use the new syntax.
• Add type hints to improve code maintainability.

[sourcery-ai]

Reviewer's Guide by Sourcery

This pull request deprecates the use of docker-compose in favor of docker compose and adds type hints to the _validate_run_request function. It also pins the foca dependency to version 0.12.1.

Sequence diagram for CI/CD workflow changes

sequenceDiagram
    participant GH as GitHub Actions
    participant Docker as Docker
    participant App as Application

    Note over GH: Updated deployment flow
    GH->>Docker: docker compose up -d --build
    Note right of Docker: Replaced 'docker-compose' with 'docker compose'
    Docker->>App: Build and start containers
    GH->>App: Wait 20s for startup
    GH->>App: Probe endpoint

Loading

Class diagram showing type hint addition to _validate_run_request

classDiagram
    class RunRequest {
        +validate()
    }
    class dict_atomic {
        <<dict>>
        +str key
        +Any value
    }
    note for dict_atomic "Added type hint: dict"
    RunRequest ..> dict_atomic: uses

Loading

File-Level Changes

Change	Details	Files
Replaced docker-compose with docker compose.	Updated the deployment script to use docker compose instead of docker-compose.	.github/workflows/main.yml
Added type hints to the _validate_run_request function.	Added type hints to the dict_atomic variable, specifying it as a dictionary.	pro_wes/ga4gh/wes/workflow_runs.py
Pinned the foca dependency to version 0.12.1.	Changed the foca dependency from >=0.12.1 to ==0.12.1.	requirements.txt

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time. You can also use
  this command to specify where the summary should be inserted.

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey @JaeAeich - I've reviewed your changes - here's some feedback:

Overall Comments:

• Consider splitting different types of changes (type hints, dependency updates, docker compose changes) into separate PRs for better review granularity
• What's the rationale for strictly pinning foca to version 0.12.1? Using exact version pinning (==) instead of minimum version (>=) can make security updates more difficult

Here's what I looked at during the review

• 🟢 General issues: all looks good
• 🟢 Security: all looks good
• 🟢 Testing: all looks good
• 🟢 Complexity: all looks good
• 🟢 Documentation: all looks good

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[JaeAeich]

@sourcery-ai review

[sourcery-ai]

Hey @JaeAeich - I've reviewed your changes - here's some feedback:

Overall Comments:

• Consider explaining the rationale for pinning pip to version <24.1 in the PR description. If this is addressing a specific issue, it might be better to fix the root cause rather than artificially constraining the pip version.

Here's what I looked at during the review

• 🟢 General issues: all looks good
• 🟢 Security: all looks good
• 🟢 Testing: all looks good
• 🟢 Complexity: all looks good
• 🟢 Documentation: all looks good

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[uniqueg]

Hey @JaeAeich - I've reviewed your changes - here's some feedback:

Overall Comments:

• Consider splitting different types of changes (type hints, dependency updates, docker compose changes) into separate PRs for better review granularity
• What's the rationale for strictly pinning foca to version 0.12.1? Using exact version pinning (==) instead of minimum version (>=) can make security updates more difficult

Here's what I looked at during the review

• 🟢 General issues: all looks good
• 🟢 Security: all looks good
• 🟢 Testing: all looks good
• 🟢 Complexity: all looks good
• 🟢 Documentation: all looks good

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

Generally a good comment, but in this case, we want to repair a broken CI because of outdated code. It makes sense to do so in one PR, especially since the changes are small.

[uniqueg]

Hey @JaeAeich - I've reviewed your changes - here's some feedback:

Overall Comments:

• Consider explaining the rationale for pinning pip to version <24.1 in the PR description. If this is addressing a specific issue, it might be better to fix the root cause rather than artificially constraining the pip version.

Here's what I looked at during the review

• 🟢 General issues: all looks good
• 🟢 Security: all looks good
• 🟢 Testing: all looks good
• 🟢 Complexity: all looks good
• 🟢 Documentation: all looks good

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

It may indeed be good to explain this. But no, we're gonna stick with the workaround for now.

[uniqueg]

Thanks for splitting up the PRs 👍 Please merge this first, then update the other PR.

And please address the one Sourcery comment by increasing your PR description (but that does not need re-review from my side).

[JaeAeich]

Consider explaining the rationale for pinning pip to version <24.1 in the PR description. If this is addressing a specific issue, it might be better to fix the root cause rather than artificially constraining the pip version.

pining pip version because of dependency resolution issues in CI, since sooner or later this will be revisited and updated with pyproject, that will eventually update all the deps.