Githawk: Alternativen zu Buddybuild?

Für eine weitere selbst gehostete Option, TeamCity(https://www.jetbrains.com/teamcity)?

Normalerweise ist die CircleCI-Auftragswarteschlange für Open-Source-Projekte viel weniger überfüllt als TravisCI.

Meine 0,02 $ aus der Verwaltung einiger der RxSwiftCommunity-Repos.

Travis ist absoluter Müll (oder ist mit der Zeit geworden).
Warteschlangen sind unerträglich und verlangsamen den Entwicklungsaufwand (das Warten von 50 Minuten auf einen 90er-Build ist nicht akzeptabel) und die Konfiguration ist relativ nervig.

Wir verlagern langsam aber sicher die meisten Repos zu CirlceCI und sind damit sehr zufrieden. Die Warteschlange ist wirklich schnell und fair, und die Konfiguration ist relativ einfach.

Habe in diesem Sinne auch tolle Dinge über Bitrise gehört.

Super schade um BB, es ist interessant, es im Auge zu behalten, da ich nicht glaube, dass Apple es töten würde - aber ja

Hatte Erfahrung mit einer älteren Version von Jenkins, als Werkzeug ist es definitiv in der Lage, würde aber ziemlich viel Wartung / Konfiguration erfordern und in der Kunst, die Dinge so offen und kollaborativ zu halten, wahrscheinlich nicht das Beste, ehrlich gesagt

Auch wenn wir uns für einen anderen "großen" Anbieter entscheiden, laufen wir das gleiche Risiko, dass er einfach von einer anderen Firma, die Monopoly spielt, mitgerissen wird

Ich würde gerne Bitrise ausprobieren, meine 2 Cent

Ich bin offensichtlich voreingenommen ;) aber so etwas wird mit App Center nicht passieren.
Bitte melden Sie sich bei Interesse.

cc @Palleas

_{Gesendet mit GitHawk}

Https://Buildozer.io unterstützt sowohl iOS als auch Android. (Offenlegung: Ich bin einer der Gründer)

Wir haben CircleCI für alle Artsy iOS-Projekte verwendet, die einen Mac für CI erfordern - die OSS-Warteschlangen waren kein Problem wie bei travis.

Ich habe den ganzen Tag damit verbracht, Bitrise und App Center auszuprobieren. Bisher sehen sie nicht so einfach zu bedienen und magisch aus wie BuddyBuild...
Ich freue mich für das BB-Team (und stolz, da ich auch in Vancouver bin), aber als User sehr sauer...
BuddyBuild war einer dieser Dienste, die einfach funktionieren und fast keine Konfiguration erfordern.

Die Funktionsweise von Buddybuild hat mir sehr gut gefallen. Ich habe Circle CI schon einmal übermüdet, aber hier sind einige Dinge zu beachten, dass es Fastlane zum Signieren und Bereitstellen für Testflug verwendet. Automatisches Signieren kann nicht verwendet werden. muss "Manuell" verwenden

Ich habe einige Zeit eingerichtet , um mit @TroubleMakerBen zu chatten, AppCenter _sieht_ wirklich nett aus. Werde mehr darüber erfahren und berichten!

Überprüfen Sie https://buildkite.com/ sie bieten ein kostenloses Konto für OSS an

Ein großer Fan von Bitrise hier. Wir verwenden es viel mit unserer Lösung https://www.appaloosa-store.com/

@sregg was genau hat bei dir im App Center nicht funktioniert? Ich helfe gerne bei allen Build-spezifischen Problemen.

@derpixeldan zum Beispiel ist die Slack-Integration alles manuell mit Webhooks im Vergleich zu nur einem Kontrollkästchen mit BB. Außerdem gibt es keine Möglichkeit, eine Build-Nummer mit einer bestimmten Nummer (dh meiner aktuellen Build-Nummer auf BB) zu beginnen. Schließlich sah das Signieren der iOS-App nicht so einfach aus wie bei BBs (ich glaube, ich habe ihnen nur meinen Apple-ID-Benutzernamen / mein Passwort gegeben und sie haben das Zertifikat und die Bereitstellung automatisch verwaltet).

Ich bin der Engineering Manager bei Microsoft für App Center Build. Wir haben ein großartiges Team, das jede Woche Verbesserungen vornimmt, und wir setzen uns für den Multiplattform-Support ein.

@sregg tolles Feedback und ich denke, dass Verbesserungen in all diesen Bereichen auf unserem Backlog stehen.

Fühlen Sie sich auch frei, mir auf Twitter unter https://twitter.com/0xlukekim eine DM mit Fragen/Bedenken/Feedback zu senden.

Ich muss sagen, dass ich von App Center sehr beeindruckt war, hauptsächlich im Sinne von "meta":

• Die Entwicklungsanstrengungen von Microsoft.
• Das Eigentum und die Fürsorge einiger Mitarbeiter zeigen, indem sie hier kommentieren.
• Ich habe es letztes Jahr in der AltConf in Aktion gesehen und es schien ziemlich nett zu sein.

Habe nicht genug Erfahrung damit, scheint aber auch ein würdiger Konkurrent zu sein :)

Hallo zusammen, ich bin Viktor von https://www.bitrise.io (CTO & Co-Founder).

Vielen Dank an alle für die Empfehlung, sie bedeutet unserem Team sehr viel !

Wollte nur Hallo sagen 👋 und euch versichern, dass wir natürlich zuhören, pingt uns gerne jederzeit über einen unserer Support-Kanäle an und auch hier beantworte ich gerne eure Fragen!

Haha, ich denke, wir können jetzt den Bieterkampf beginnen 😄

Mein GitHawk bringt alle CIs auf den Hof 🤓

Es gibt auch https://buddy.works Ich habe ihren Service nicht genutzt, also schwer zu sagen, ob sie gut sind. Sie haben definitiv einen coolen Namen ;P

Ich bin von BuddyBuild zu Bitrise gewechselt (wir wollen wirklich einen Ort für unser iOS und Android). Es hat einiges Lesen der Dokumente und auch einiger Git-Repos des Schrittes erfordert, aber es lief ziemlich reibungslos, dauerte ungefähr einen Tag neben anderen Dingen.

@sregg Nur um zu erwähnen, dass wir den Schritt "BuildNumber anpassen" auf += 640 verwenden, da wir ihn für versionCode und automatisch von BB bereitgestellt wurden.

Die Hauptunterschiede, die ich bei Bitrise gegenüber BuddyBuild festgestellt habe (abgesehen davon, dass in BB so ziemlich alles GUI-basiert ist), bestand darin, den Gradle-Build in mehrere Schritte aufzuteilen. BuddyBuild würde (möglicherweise effizienter) alles erstellen, was Sie verlangen, und dann die relevanten Dinge herausholen, beispielsweise für Bereitstellungs-E-Mails oder die Veröffentlichung im Play Store. Mit Bitrise haben Sie einige Möglichkeiten, die ich sehen könnte: 1. Aufteilen in mehrere Build/Gradle-Schritte, zB für UI/Android Tests, für Ihre Test-Builds [2x3=6 Varianten für uns], einer für Ihre App/Play Store Deployment-Artefakte, mit einigen Aufräumschritten dazwischen (zB ändere ich den Deploy-Ordner nach to verhindern, dass E-Mails ausgehen, bei denen Filter nicht ausreichen) ... oder 2. mit Bash-Skript vertraut sein und einen Skriptschritt haben, der die Pipe-Map-ENV-Variablen aufteilt, damit sie in späteren Schritten einfacher verwendet werden können.

Es wäre auch schön, mehr Beispiele zu haben, die die Slack-Nachrichten so einstellen, dass sie so etwas enthalten wie die, die BB standardmäßig gesendet hat, z.

Die anderen wären Funktionen, die wir nicht verwendeten, Testerverwaltung (wir verwenden Play Store Alpha und TestFlight) und Shake für Crash / Crash-Logger (wir bevorzugen Firebase).

Eine der wirklich coolen Funktionen ist die Möglichkeit, Ihren Workflow nicht nur als .yml-Datei anzuzeigen und zu bearbeiten, sondern diese auch herunterzuladen und lokal mit der CLI auszuführen.

Um ehrlich zu sein ist es viel mehr Arbeit, als wir es gewohnt waren, das ist der Punkt, wenn man monatlich bezahlt, oder? Aber es ist so ziemlich eine einmalige Sache und der Bonus ist zusätzliche Anpassbarkeit. Alles in allem macht es seine Arbeit sehr gut und das zu einem guten Preis. Ich bin zufrieden mit diesem Schalter. Ich bin sicher, CircleCI ist auch gut (wir verwenden das für unser Back-End).

Es ist auch erwähnenswert, dass die gesamte Infra von Bitrise OSS ist - https://github.com/bitrise-io/bitrise.io

Danke @richardleggett für das Feedback, ich werde das mit dem Team besprechen!

Besonders die Slack-Nachricht - ich denke, es ist längst überfällig, dort eine "ausgefallenere" (nützlichere) Standardnachricht zu haben, anstatt Sie zu zwingen, Ihre "Traum" -Nachricht direkt nach dem Einfügen des Schritts zu erstellen. Flexibilität ist wichtig, aber auch der Standardwert / die Setup-Erfahrung (und die Geschwindigkeit). Sie können die Nachricht danach sowieso optimieren, sodass es kein Problem gibt, den Standard ausführlicher zu gestalten.

Gradle: wird es auch mit dem Werkzeugteam besprechen, danke für die Hervorhebung!

Ich habe die Dose darauf getreten (langsam meine Angst erhöht). Wollte auf diesen Blogbeitrag verlinken, in dem Alternativen untersucht werden, falls es dort weitere Informationen gibt.

Ich möchte einige Zeit mit @orta und @krausefx verbringen, während bin , um meine " Nordstern" -Vision für die Automatisierung dieses Projekts (über CI hinaus) zu diskutieren. Werde mich wieder melden, sobald ich die Energie aufbringen kann, wirklich daran zu arbeiten.

Danke für das Update zu diesem @rnystrom. Ich kann das gut nachfühlen. 😕

@rnystrom danke für den Blogbeitrag und es tut mir leid zu hören, dass du Probleme mit der Einrichtung der Distribution auf Bitrise hattest. Ich bin mir nicht sicher, ob Sie es gesehen haben, aber wir haben jetzt Auto Provisioning für Code Signing integriert, das nach der Konfiguration die iOS-Signaturdateien automatisch für Sie verwalten kann: https://blog.bitrise.io/ios-auto-provision-step

Wie auch immer, ich wollte mich nur für das Ausprobieren von Bitrise bedanken und Ihnen mitteilen, dass wir immer gerne helfen, falls Sie Bitrise noch einmal ausprobieren möchten. Zögern Sie nicht, mich überall anzupingen, zB auf unserem Slack (http://chat.bitrise.io).

@viktorbenei Für das, was es wert ist, ist das nicht Ryans Blogpost!

Autsch, mein Böser, hier ist es noch ziemlich früh am Morgen 😅 Sorry Herren und danke @Sherlouk !

Habe gestern Abend tatsächlich einen Bitrise-Job angetreten. Werde wieder berichten!

_{Gesendet mit GitHawk}

Bitrise-Build ist grün! Genauso einfach einzurichten wie BB. Ich glaube, wir haben einen Gewinner.

_{Gesendet mit GitHawk}

Freut mich zu hören

Tatsächlich sollte das anfängliche Setup ziemlich glatt sein, ähnlich wie bei BB. Der Hauptunterschied ist die Konfigurationsoberfläche danach. Der Ansatz von BB bestand darin, eine einfache Benutzeroberfläche bereitzustellen, die impliziert, dass bestimmte Dinge möglicherweise nicht möglich sind / nicht geändert werden können, während wir uns hauptsächlich auf Flexibilität konzentrierten, damit Sie jeden Aspekt des Prozesses festlegen können, wenn Sie möchten (aber dies ist mit einer gewissen Komplexität & steilere Lernkurve). Wir wissen, dass diese Lernkurve insbesondere für Hobbyprojekte zu viel sein kann und arbeiten daran, sie zu verbessern. Für dieses Jahr sind einige Dinge geplant, um die Bereitstellung usw. von Konfigurationen zu vereinfachen ;)

https://appcenter.ms scheint vielversprechend

Im Namen der Transparenz sind wir im Moment hier: Ich habe sowohl Bitrise als auch App Center CI, die GitHawk bauen. Beide Dienste sind ziemlich einfach zu bedienen, daher möchte ich beide ausprobieren, um mehrere Beta-Builds und einen einzigen App Store-Build bereitzustellen, um meinen Prozess zu dokumentieren.

Hier meine ersten Gedanken

Bitrise

Vorteile

• Tolle Unterstützung (h/t @viktorbenei)
• Ziemlich schnell gebaut
• Bereitstellung über Fastlane
• Extreme Anpassung und Granularität der Build-Schritte
• Plattform ist Open Source (ish)
• Builds automatisch von master an ITC übertragen (ich _liebe_ das)

Nachteile

• Kein kostenloser Open-Source-Plan (_noch_)
• Startup (könnte erworben werden oder verschwinden)

App Center

Vorteile

• Builds sind _sehr_ schnell
• Weniger Anpassung = mehr Rationalisierung
• Maßgeschneidert für iOS/Android-Bereitstellung
• @TroubleMakerBen rockt
• Unterstützt von Microsoft
  
  
  
  • Geht wahrscheinlich nicht so schnell weg
  
  
  • ++Ressourcen
  
  

Nachteile

• Kein kostenloser Open-Source-Plan (_noch_)
• Erfordert ein gemeinsames Ziel zum Erstellen
• Automatisierte Bereitstellung tbd (bestätigte Ankunft)
• Zu viele Dinge, die wir nicht verwenden werden (z. B. brauche ich das App Center SDK nicht)
• Die Protokollausgabe ist _sehr ausführlich_, schwer zu findende Build-Fehler
• Keine GitHub-Statusintegration

Danke fürs Teilen von @rnystrom ! Nur eine Korrektur, die Webservice-Komponente von bitrise ist nicht Open Source, daher ist es (noch) nicht möglich, die API und die Web-UI selbst zu hosten ;)). Alle zum Ausführen der Konfiguration verwendeten Tools (der Workflow-Editor, die Runner-CLI, ...) sind Open Source, sodass Sie die Build-Konfiguration herunterladen und auf Ihrem eigenen Mac (oder auf jedem Mac/Linux) ausführen können, ähnlich wie Überholspur.

Nur eine Frage zum Vergleich

Bitrise: Nachteile: Kein kostenloser Open-Source-Plan (noch)

Hat AppCenter einen Open-Source-Plan? Vielleicht haben sie es übersehen, AFAIK haben sie auch keine. Ich bin wirklich nur neugierig, da ich auf der Website von Appcenter nichts passendes finden konnte.

Keine GitHub-Statusintegration

Das ist ein großes ☹️

@viktorbenei wird aktualisiert! Auch noch nicht

_{Gesendet mit GitHawk}

Hallo Leute,

Thx für das Feedback und den Vergleich. Das gefällt mir und unsere PMs schauen sich diesen Thread an.

Automatisierte Bereitstellung tbd (bestätigte Ankunft)

Wir arbeiten derzeit hart daran, den Vertrieb zu verbessern. Bleiben Sie dran.

Hat AppCenter einen Open-Source-Plan? Vielleicht haben sie es übersehen, AFAIK haben sie auch keine. Ich bin wirklich nur neugierig, da ich auf der Website von Appcenter nichts passendes finden konnte.

Wir haben noch keinen OSS-Plan.

Gruß an alle und ein schönes Wochenende!

Dies könnte jetzt relevant sein https://github.com/fastlane/ci

@KrauseFx Ich habe das gesehen und bin so

Warum nach Features fragen, wenn wir als Community sie entwickeln können? Und Google unterstützt das? könnte nicht viel mehr verlangen.

Ich freue mich wirklich darauf, Code dazu beizutragen, während es fortschreitet, und es auf unseren Workflow anzuwenden, wenn es reift.

Danke für alles, was ihr für die Community tut!

@KrauseFx Spieler 3 hat das Spiel betreten

_{Gesendet mit GitHawk}

lolz

Ich glaube nicht, dass das App Center pro Commit [ci skip] wie Syntax unterstützt

@dkhamsing leider (noch) nicht.

Ein echtes Plus für Buddybuild, das ich liebte, war die Art und Weise, wie sie Vorher/Nachher/Differenzen in den Testergebnissen anzeigen , wenn ein

Weiß jemand, ob eines dieser anderen Systeme eine ähnliche Funktion hat?

Unterstützt App Center das Erstellen aus einer Pull-Anfrage?? Ich bin sehr verwirrt cc @TroubleMakerBen

@dkhamsing tut es!

edit: egal

_{Gesendet mit GitHawk}

@dkhamsing App Center unterstützt Build on PUSH, aber noch nicht Build on PR (Build on Merge).

Ah ich sehe. Thx Ryan, Ben

_{Gesendet mit GitHawk}

Nach dem Lesen dieses Threads scheint es ein Zwei-Pferde-Rennen zu sein: Bitrise und App Center. Doch das Thema UI-Tests hat noch niemand angesprochen: Ich fand es toll, wie man in BB mit wenigen Klicks Espresso-Tests auf einem virtuellen Gerät durchführen konnte. Unterstützt eine der beiden diskutierten Plattformen dies?

https://docs.microsoft.com/en-us/appcenter/test-cloud/

_{Gesendet mit GitHawk}

@dkhamsing App Center Test führt tatsächlich UI-Tests auf physischen Geräten durch – wir haben ein paar Tausend. Nein, Bilder sind nicht zu sehen ;)

Wir versuchen tatsächlich, eine neue CI-Lösung zu finden.

• AppCenter : ähnlich wie bb, bietet aber keine PR-Unterstützung, ich denke, es ist eher auf Managementleute ausgerichtet, auch die Protokolle bieten keinen Stack, wenn eine Aufgabe fehlschlägt.

• Bitrise: Sehr konfigurierbar, bietet viele offene "Schritte" wie Codecoverage, Deployment, Sign, UnitTest, UITest, Build, Deliver, Clean und Custom, da Sie die Möglichkeit haben, es zu konfigurieren kann bei gegebenem Push, PR, etc. Schritte auslösen

• Nevercode Sehr konfigurierbar, Sie können wählen zwischen gradlew Task pro Branche, Build PR, kein kostenloser Plan.

Ich denke, Bitrise bietet zumindest viele Funktionen, die wir ausnutzen können!

Über den oben geposteten Link zum Testen im App Center

1. Überprüfen Sie die Kernkonzepte
   Das Verständnis der Kernkonzepte der Test Cloud-Erfahrung verbessert die Benutzerfreundlichkeit, Navigation und Kommunikation mit Support. Es wird empfohlen, sich mit diesen Konzepten vertraut zu machen, bevor Sie Ihre ersten Tests durchführen.

Was zum Teufel... Ich möchte keine Konzepte überprüfen, weder Kern noch sonstiges, ich möchte nur, dass es mit 2 Klicks funktioniert, wie es bei BB der Fall war :( Ich habe keine 10 Stunden Zeit, um diese Arbeit zu machen, Ich bin Programmierer, kein Devops-Ingenieur...

Ja, die App Center-Dokumentation könnte optimiert werden

_{Gesendet mit GitHawk}

@acristescu

Nach dem Lesen dieses Threads scheint es ein Zwei-Pferde-Rennen zu sein: Bitrise und App Center. Doch das Thema UI-Tests hat noch niemand angesprochen: Ich fand es toll, wie man in BB mit wenigen Klicks Espresso-Tests auf einem virtuellen Gerät durchführen konnte. Unterstützt eine der beiden diskutierten Plattformen dies?

(noch) kein einziger Klick, aber in mehrfacher Hinsicht leistungsfähiger: https://blog.bitrise.io/introducing-solid-and-snappy-virtual-device-testing-for-android

Wir arbeiten daran, das Setup zu vereinfachen (deshalb ist es noch "Beta", nicht wegen fehlender Funktionalität ;)).

@acristescu @dkhamsing Wir wissen es! Lassen Sie das Feedback kommen.

@viktorbenei Ich werde es versuchen, aber oh mein Gott, der Kunststil ist

Kein Problem @acristescu , ich

Ich beschloss, sie beide mit einem einfachen Repo ( https://github.com/acristescu/GreenfieldTemplate ) auszuprobieren und zu sehen, wo ich hinkomme. Bisher habe ich App Center ausprobiert und ein paar Haken gefunden:

• gelöst (es konnte die Gradle-Build-Tools nicht finden!), müssen Sie das Repository google() manuell zum Gradle Ihres Projekts hinzufügen
• es hat die Build-Nummer von 1 neu gestartet, während ich bereits eine 42 im Play Store veröffentlicht habe, Google wird den Build einfach ablehnen!)
• Ich konnte nicht finden, wie man kostenlos auf einem virtuellen Gerät testet, nur auf echten Geräten mit einer kostenlosen 30-Tage- Testversion .
• Ich bin mir nicht sicher, ob die Komponententests ausgeführt wurden, weil

##[warning]No test result files matching /Users/vsts/agent/2.127.0/work/1/s/**/build/test-results/TEST-*.xml were found, so publishing JUnit test results is being skipped.

Bin mir nicht sicher was das soll...

Bitrise: Auf der positiven Seite war das Setup genauso schmerzlos, obwohl ich denke, dass ich, wenn ich etwas ändern muss, eine yml-Datei aufrufen und daran herumfummeln muss (Update: habe eine Sache namens Workflow-Editor gefunden. Es sieht beängstigend aus, aber mächtig) . Haken:

• es hat mich nie gefragt, welche Variante ich bauen soll, und die falsche gewählt. Ich wollte prodRelease aber aus irgendeinem Grund hat es sich entschieden, genau die anderen beiden mockDebug und prodDebug . Ich kann nicht finden, wo man das ändern kann, aber ich bin mir ziemlich sicher, dass es einen geben muss.
• Build dauerte länger, 4 Minuten statt 2 Minuten 16 für das App Center. Liegt das vielleicht an obigem Problem?
• sehe nirgendwo in den Protokollen eine Erwähnung von Junit-Tests. Ich bezweifle, dass es sie lief. Nicht offensichtlich, wie man sie hinzufügt, vielleicht irgendwo im Workflow-Editor? (Update hat ungefähr 10 Minuten lang mit dem Workflow-Editor herumgebastelt und es gefunden. Bonuspunkte dafür, dass ich die Freiheit habe, auszuwählen, welches test Ziel ausgeführt werden soll)
• Ich bin mir nicht sicher, welche Build-ID verwendet wurde, wie kann ich das überhaupt sehen?

Thx für die Veröffentlichung dieser

_{Gesendet mit GitHawk}

Danke @acristescu für das ausführliche Feedback, das
Weiter so!

Es hat zwei Stunden gedauert, aber ich habe es geschafft, das App Center davon zu überzeugen, auf Google Play hochzuladen. Ich kann es jedoch anscheinend nicht überzeugen, dies automatisch zu tun, ich musste das signierte APK aus dem App Center herunterladen und dann wieder in den Abschnitt Bereitstellen/Speichern (!) hochladen, damit es funktioniert. Klingt furchtbar verworren, was mache ich falsch?

PS: Um die Verletzung noch schlimmer zu machen, wurde BuddyBuild mehrmals in der gleichen Zeitspanne bereitgestellt, da ich anfangs vergessen hatte, es zu deaktivieren, und es funktioniert einfach automatisch ohne menschliches Eingreifen ...

Hallo @acristescu ,

Betreff: https://github.com/rnystrom/GitHawk/issues/1330#issuecomment -368228417

es hat mich nie gefragt, welche Variante ich bauen soll, und die falsche gewählt. Ich wollte prodRelease, aber aus irgendeinem Grund hat es sich entschieden, genau die anderen beiden mockDebug und prodDebug zu erstellen. Ich kann nicht finden, wo man das ändern kann, aber ich bin mir ziemlich sicher, dass es einen geben muss.

Tatsächlich fügt unser aktueller Scanner einen Gradle Runner-Schritt hinzu, wobei assembleDebug für den Basisworkflow konfiguriert ist. Uns ist klar, dass dies möglicherweise nicht einfach genug ist, aber kurz gesagt, wenn Sie prodRelease erstellen möchten, lautet die Gradle-Aufgabe assembleProdRelease . Wenn Sie lint ausführen möchten, lautet die Gradle-Aufgabe lint . Sie können all dies mit dem Schritt „Gradle Runner“ tun, tatsächlich kann Gradle mehrere Aufgaben bearbeiten, sodass Sie lint und dann assembleProdRelease ausführen können, können Sie dies auch als Aufgabe angeben: lint assembleProdRelease die beides tun wird.

Wir arbeiten an neuen Schritten und neuen Scanner Standard configs , die dies einfacher machen, mit spezifischeren Schritten (zB ein „Lint“ Schritt, der die gradle läuft lint Aufgabe, statt Sie zu benötigen , diese Aufgabe zu setzen in Schritt "Gradle Runner") 😉

Build dauerte länger, 4 Minuten statt 2 Minuten 16 für das App Center. Liegt das vielleicht an obigem Problem?

Tatsächlich scheint dies der Fall zu sein, da assembleDebug in Ihrem Fall höchstwahrscheinlich 2 separate APKs / Varianten anstelle der einzelnen "ProdRelease" generiert.

sehe nirgendwo in den Protokollen eine Erwähnung von Junit-Tests. Ich bezweifle, dass es sie lief.

Geben Sie test als Gradle-Aufgabeneingabe des Gradle-Runner-Schritts an, der Ihre Tests ausführt - oder fügen Sie den Gradle-Einheitentest- Schritt hinzu, der standardmäßig für die Ausführung dieser Gradle-Aufgabe konfiguriert ist.

Ich bin mir nicht sicher, welche Build-ID verwendet wurde, wie kann ich das überhaupt sehen?

Wenn Sie meinen, ob wir die Build-Nummer auf die Build-Nummer von bitrise.io setzen: Standardmäßig tun wir dies nicht, Sie können dies tun, indem Sie beispielsweise den Schritt Change Android versionCode und versionName hinzufügen.

Nochmals vielen Dank für Ihr Feedback, wir hören zu und planen bereits, diese Punkte des Setup-Erlebnisses zu verbessern! ;)

Tolle Diskussion. Ich finde es schwierig, eine BuddyBuild-Alternative zu finden, die Carthage unterstützt.

Ich habe mir Nevercode angesehen, sie unterstützen nur Kakaofrüchte.

Ich glaube, das App Center unterstützt Karthago.

Irgendwelche anderen?

@jamesone

Ich denke, die beste Option für Sie könnte Bitrise sein. Sie bieten eine Plattform wie Pipelines bitbucket , die Sie auch mit Steps nach Ihren Bedürfnissen konfigurieren können.

Eigentlich sind wir von bb zu bitrise gewechselt, wir verwenden Android und iOS und alles ist perfekt!

Awesome @cbedoy Was hast du mit den installierbaren Builds gemacht, die buddybuild für alle deine Branches bereitstellt? Hat Bitrise dafür eine Integration ODER Unterstützung?

Sie können Workflows (viele _Schritte_) auslösen, wenn Sie Pushen, eine PR oder ein Tag erstellen.

Sie können auch Builds pro Zweig planen.

Sie sollten überprüfen:

https://devcenter.bitrise.io/bitrise-cli/workflows/
https://devcenter.bitrise.io/bitrise-cli/steps/

Wenn Sie verstehen, wie Bitrise funktioniert, können Sie Workflows erstellen, die auf Ihren Anforderungen basieren, dh ich möchte einen Workflow, bei dem nur UnitTesting ausgeführt wird, wenn jemand eine PR erstellt, oder ich möchte einen Workflow, bei dem die .ipa erstellt und generiert werden, wenn der Master getaggt wurde.

Bitrise ist so etwas wie Docker-Images, bei denen Sie _steps_ eines Drittanbieters zum Ausführen von UnitTest, CodeCoverage oder Archivieren und Bereitstellen auswählen können.

Toller Kerl! Klingt wirklich interessant. Ich werde es prüfen.