Add test job to Swift CI workflow

[tkausch]

PR Type

Enhancement, Tests

---

Description

• Add dedicated test job to CI workflow with Ubuntu runner

• Configure httpbin Docker container for integration testing

• Separate test execution from build job with dependency

• Set HTTPBIN_BASE_URL environment variable for tests

---

Diagram Walkthrough

flowchart LR
  A["Build Job<br/>macOS"] -->|needs| B["Test Job<br/>Ubuntu"]
  B --> C["Setup Swift 5.9"]
  C --> D["Start httpbin Container"]
  D --> E["Run Tests"]

Loading

File Walkthrough

	Relevant files
Enhancement	Swift.yml Add test job with httpbin Docker integration                          .github/workflows/Swift.yml Added new test job that runs on Ubuntu after build completes Integrated httpbin Docker container startup for integration testing Moved test execution to separate job with environment variable configuration Maintained Swift 5.9 setup and checkout steps in test job +17/-1

---

[qodo-code-review]

PR Compliance Guide 🔍

(Compliance updated until commit 26ea914)

Below is a summary of compliance checks for this PR:

Security Compliance
⚪	Unsafe fixed port binding Description: The workflow starts a Docker container exposing httpbin on host port 80, which can conflict with other services on the runner or be blocked; using a high, random, or ephemeral port with explicit base URL is safer and more reliable. Swift.yml [37-45] Referred Code - name: Start httpbin container run: | docker run -d -p 80:80 kennethreitz/httpbin sleep 5 # give it a few seconds to start - name: Run tests env: HTTPBIN_BASE_URL: http://localhost # if your tests need it run: swift test -v
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
🔴	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Hardcoded Secrets: Test code includes hardcoded bearer tokens and credentials constants which risk exposure if ever logged or reused beyond isolated testing. Referred Code let BearerToken = "ThisIsAVeryLongBearerToken" let BearerToken2 = "ThisIsAnotherVeryLongBearerToken" let User = "User" let Password = "Password" Learn more about managing compliance generic rules or creating your own custom rules
⚪	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Test Logging: The PR adds/changes test code and CI workflow without introducing or modifying any application audit logging, so audit trail coverage cannot be assessed from the diff alone. Referred Code guard let url = URL(string: "http://0.0.0.0:80") else { XCTFail("Bad test server URL!") return } self.url = url Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: CI Robustness: The workflow starts a dockerized httpbin with a fixed 5s sleep and no health check or retry, which may cause flaky failures without contextual error handling in CI. Referred Code - name: Start httpbin container run: | docker run -d -p 80:80 kennethreitz/httpbin sleep 5 # give it a few seconds to start - name: Run tests env: HTTPBIN_BASE_URL: http://localhost # if your tests need it run: swift test -v Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: HTTP Usage: Tests were switched to use http over localhost and expose port 80, which is acceptable for local CI but should be verified to avoid weakening assumptions about secure transport in production paths. Referred Code - name: Start httpbin container run: | docker run -d -p 80:80 kennethreitz/httpbin sleep 5 # give it a few seconds to start - name: Run tests env: HTTPBIN_BASE_URL: http://localhost # if your tests need it run: swift test -v Learn more about managing compliance generic rules or creating your own custom rules

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

---

Previous compliance checks

Compliance check up to commit 59477d9

Security Compliance
⚪	Insecure port exposure Description: The workflow starts a Docker container exposing port 80 to the host on a shared CI runner, which may conflict with other services and broaden attack surface; prefer binding to 127.0.0.1:8080 or an ephemeral port to limit exposure. Swift.yml [35-43] Referred Code - name: Start httpbin container run: | docker run -d -p 80:80 kennethreitz/httpbin sleep 5 # give it a few seconds to start - name: Run tests env: HTTPBIN_BASE_URL: http://localhost # if your tests need it run: swift test -v
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
⚪	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: No audit logs: The workflow changes add a test job and container usage but do not introduce or modify any application logging of critical actions, so it's unclear whether audit trail requirements are impacted or satisfied. Referred Code test: runs-on: ubuntu-latest needs: build steps: - uses: actions/checkout@v4 - uses: swift-actions/setup-swift@v2 with: swift-version: "5.9" - name: Start httpbin container run: | docker run -d -p 80:80 kennethreitz/httpbin sleep 5 # give it a few seconds to start - name: Run tests env: HTTPBIN_BASE_URL: http://localhost # if your tests need it run: swift test -v Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Minimal error handling: The new test job steps (docker run, sleep, swift test) lack explicit error checks or retries beyond default GitHub Actions behavior, which may not robustly handle container startup failures or transient issues. Referred Code - name: Start httpbin container run: | docker run -d -p 80:80 kennethreitz/httpbin sleep 5 # give it a few seconds to start - name: Run tests env: HTTPBIN_BASE_URL: http://localhost # if your tests need it run: swift test -v Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Potential log exposure: The workflow runs tests with verbose output and sets HTTPBIN_BASE_URL, but there is no explicit control preventing tests from logging sensitive data; assessment depends on test code not shown here. Referred Code env: HTTPBIN_BASE_URL: http://localhost # if your tests need it run: swift test -v Learn more about managing compliance generic rules or creating your own custom rules

[qodo-code-review]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
High-level	Combine build and test jobs The current workflow builds the code in the build job and then again in the test job. To avoid this redundant work, combine the build and test steps into a single job for better efficiency. Examples: .github/workflows/Swift.yml [26-43] test: runs-on: ubuntu-latest needs: build steps: - uses: actions/checkout@v4 - uses: swift-actions/setup-swift@v2 with: swift-version: "5.9" - name: Start httpbin container ... (clipped 8 lines) Solution Walkthrough: Before: jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Build run: swift build -v test: runs-on: ubuntu-latest needs: build steps: - uses: actions/checkout@v4 - name: Start httpbin container run: docker run ... - name: Run tests run: swift test -v # This command rebuilds the project After: jobs: build_and_test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Build run: swift build -v - name: Start httpbin container run: docker run ... - name: Run tests run: swift test -v # This command uses the existing build artifacts Suggestion importance[1-10]: 8 __ Why: The suggestion correctly identifies a significant inefficiency where the code is built twice, and proposes a valid solution to combine the jobs, which would simplify the workflow and improve CI execution time.	Medium
Possible issue	Replace fixed sleep with health check Replace the fixed sleep 5 with a robust health check loop that polls the httpbin container to ensure it is ready before proceeding. This prevents flaky tests caused by variable container start-up times. .github/workflows/Swift.yml [36-38] run: | docker run -d -p 80:80 kennethreitz/httpbin - sleep 5 # give it a few seconds to start + # Wait up to 30 seconds for httpbin to become available + timeout 30s bash -c 'until curl -s --fail http://localhost/status/200 > /dev/null; do echo "Waiting for httpbin..."; sleep 1; done' Apply / Chat Suggestion importance[1-10]: 8 __ Why: The suggestion correctly identifies that using a fixed sleep can lead to flaky tests and proposes a much more robust health check loop, which significantly improves the reliability of the CI job.	Medium
General	Improve Docker container lifecycle management Improve Docker container lifecycle management by adding the --rm flag to automatically remove the container on exit and --name for easier management. This follows best practices and prevents resource leaks. .github/workflows/Swift.yml [36-38] run: | - docker run -d -p 80:80 kennethreitz/httpbin + docker run --rm --name httpbin -d -p 80:80 kennethreitz/httpbin sleep 5 # give it a few seconds to start [Suggestion processed] Suggestion importance[1-10]: 6 __ Why: The suggestion improves CI hygiene by applying Docker best practices for container lifecycle management, which is particularly important for preventing resource leaks on self-hosted runners.	Low
Update

[qodo-code-review]

Suggestion: Improve Docker container lifecycle management

Suggested change

	- name: Start httpbin container
	run: |
	run: |
	docker run --rm --name httpbin -d -p 80:80 kennethreitz/httpbin
	sleep 5 # give it a few seconds to start