Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

build-for-testing and CI/CD

Open
#531 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
ruby
Domain
devops, testing

Research direction

Start by reading the code that resolves source paths from Xcode test results and the tests covering report generation; the issue does not name specific files. Check whether Slather can accept a source directory when those paths point to another runner. Done means reports can be generated from a build on one machine and test results on another, or the supported limitation and workaround are documented.

Written by the indexing model from the issue text.

Description

i have a CI/CD pipeline where one job builds my project for testing and then a subsequent job runs the tests with the generated .xctestrun from the build job. this pipeline optimization has worked great for me. however, i run into issues when trying to use Slather.

due to jobs being distributed across a pool of runners, if the build and test jobs run on different machines, Slather does not generate any reports because it can't find the files used to build. it looks like Slather is using the absolute file paths encoded in the test results output which references paths that are only valid on the runner that executed the build job, which of course don't exist on the runner that executed the test and report job.

how does one work around this? is there a way to provide the source directory rather than rely on the absolute file paths encoded in the test results? or am i to resort to just executing my build and test commands in the same job?

Dominant language
Ruby
Stars
1.6k
Forks
239
Avg merge
1d 9h
Merged PRs (30d)
2

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from SlatherOrg/slather

All issues in SlatherOrg/slather

Similar issues

More Ruby issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.