<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=197909) </details> <!--IssueSummary end--> The following discussion from !22418 should be addressed: - [ ] @reprazent started a [discussion](https://gitlab.com/gitlab-org/gitlab/merge_requests/22418#note_272577383): (+4 comments) > If the only reason we need sidekiq is to have the `fork_project`-spec helper work, perhaps we should consider running it inline there: > > ```ruby > create_repository = params.delete(:repository) > # Avoid creating a repository > if create_repository > RepositoryForkWorker.new.perform(...) # with the right argument > else > allow(RepositoryForkWorker).to receive(:perform_async).and_return(true) > shell = double('gitlab_shell', fork_repository: true) > allow(service).to receive(:gitlab_shell).and_return(shell) > end > ``` > > Or is there another reason we need to have sidekiq jobs run? --- We should look into how it'll affect the rest of the specs if we go with the suggested approach. If it is going to affect it negatively and it's significant, look into another approach.