Konfigurowanie multidexing nie rozwiązać ten problem dla mnie.
Jednak udało mi się znaleźć rozwiązanie ... w pewnym sensie. Zasadniczo wymagało to utworzenia żądania pobrania dla drugiej gałęzi z tego samego zatwierdzenia, co kompilacja, która uległa awarii. Kompilacja dla tego żądania ściągania powiodła się, a następnie Bitbucket pomyślał, że pierwotne żądanie ściągnięcia było w porządku i umożliwiło nam scalenie, mimo że nie wprowadziliśmy żadnych zmian w tej gałęzi. Jest tam trochę niewyjaśnionego dziwactwa, ale technika zadziałała.
Oto jak to zrobiłem:
Załóżmy, że oddział, który zawodzi nazywa bad-branch
.
Utworzono nowy oddział o nazwie bad-branch-copy
dla zatwierdzenia, które było powszechne między bad-branch
i develop
. Następnie połączyłem bad-branch
w bad-branch-copy
. Końcowym rezultatem tego było szybkie przewijanie do przodu, tak że bad-branch-copy
zakończyło się tym samym zatwierdzeniem, co bad-branch
. Spodziewałem się osobnego zatwierdzenia, więc wynik ten zaskoczył mnie, ale i tak chwytałem się słomek, więc szedłem dalej.
Następnie wepchnąłem bad-branch-copy
do GitHub i utworzyłem żądanie ściągnięcia od bad-branch-copy
do develop
. Wywołało to kompilację opartą na bad-branch-copy
->develop
, która zakończyła się pomyślnie.
W tym momencie buddybuild pokazał udaną kompilację na bad-branch-copy
->develop
i nadal wykazywał awarię na bad-branch
->develop
. Jednak Bitbucket pokazał udaną kompilację na żądanie pobrania dla bad-branch
. Tak, to prawda: buddybuild pokazał awarię, ale Bitbucket powiedział, że wszystko jest w porządku.
Wtedy byliśmy w stanie połączyć żądanie ściągnięcia bad-branch
i wszystko było dobrze ze światem. Proszę, nie pytaj mnie dlaczego, nie odpowiem. :)
Myślę, że to samo może być osiągnięte z
git checkout bad-build
git checkout -b bad-build-copy
git push origin bad-build-copy
następnie tworząc prośbę popytu na złe-build-kopii.
czy umożliwiasz mutlidex true i added library dla mutlidex? –
Tak, edytowałem pytanie –
@ m.myalkin Znaleziono jakieś rozwiązanie? – AndiGeeky