You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's common for us to create a branch and open a PR in one repo (e.g. rspec-support) and also create a branch and open a PR in another repo (e.g. rspec-core) that relies upon some new API added to rspec-support. When this happens, it can cause confusing build failures, as is the case right now for rspec/rspec-support#237, rspec/rspec-core#2063 and rspec/rspec-expectations#844. Using that as an example, here's the problem:
The rspec-support adds a new API intended for use by other rspec repos -- in this case, RSpec::Support::AllExceptionsExceptOnesWeMustNotRescue.
The rspec-core and rspec-expectations PRs both use this new API.
In the rspec-core PR, the build is failing when it hits the part that runs the rspec-mocks specs against the rspec-core changes.
In the rspec-expectations PR, the build is failing when it hits the part that runs the rspec-core specs against the rspec-expectations changes.
In both cases, when the build runs the specs from the other rspec repo, it does so after using the master Gemfile of the other repo -- and the master Gemfile uses the master branch of rspec-support. However, while the rspec-mocks specs run, they hit the situation where rspec-core uses RSpec:Support::AllExceptionsExceptOnesWeMustNotRescue but that module is not defined because it's not running against the rspec-support branch that defines that module. A similar thing is happening for the rspec-expectations build failure: it uses RSpec:Support::AllExceptionsExceptOnesWeMustNotRescue in the contain_exactly matcher and the rspec-core specs use that matcher, so when the rspec-core specs run using rspec-support master and the rspec-expectations PR branch, it fails.
To solve this problem, we need to make sure that when running a CI build, we use the same commit of all rspec repos for every part of the build. The "main" repo (the one that triggered the build) is the one that should determine what SHAs should be used for each RSpec repo.
It's common for us to create a branch and open a PR in one repo (e.g. rspec-support) and also create a branch and open a PR in another repo (e.g. rspec-core) that relies upon some new API added to rspec-support. When this happens, it can cause confusing build failures, as is the case right now for rspec/rspec-support#237, rspec/rspec-core#2063 and rspec/rspec-expectations#844. Using that as an example, here's the problem:
RSpec::Support::AllExceptionsExceptOnesWeMustNotRescue
.master
Gemfile of the other repo -- and the master Gemfile uses themaster
branch of rspec-support. However, while the rspec-mocks specs run, they hit the situation where rspec-core usesRSpec:Support::AllExceptionsExceptOnesWeMustNotRescue
but that module is not defined because it's not running against the rspec-support branch that defines that module. A similar thing is happening for the rspec-expectations build failure: it usesRSpec:Support::AllExceptionsExceptOnesWeMustNotRescue
in thecontain_exactly
matcher and the rspec-core specs use that matcher, so when the rspec-core specs run usingrspec-support
master and therspec-expectations
PR branch, it fails.To solve this problem, we need to make sure that when running a CI build, we use the same commit of all rspec repos for every part of the build. The "main" repo (the one that triggered the build) is the one that should determine what SHAs should be used for each RSpec repo.
I think some intelligence could be added to https://github.com/rspec/rspec-dev/blob/master/travis/script/clone_all_rspec_repos to do this.
Anyone want to tackle this, @rspec/rspec ?
The text was updated successfully, but these errors were encountered: