Githawk: Alternatif untuk Buddybuild?

Untuk opsi lain yang dihosting sendiri, TeamCity(https://www.jetbrains.com/teamcity)?

Biasanya, antrian pekerjaan CircleCI untuk proyek sumber terbuka jauh lebih sedikit daripada TravisCI.

$0,02 saya dari mengelola beberapa repo RxSwiftCommunity.

Travis adalah sampah mutlak (atau telah menjadi dari waktu ke waktu).
Antrian tidak dapat ditoleransi dan memperlambat upaya pengembangan (menunggu 50 menit untuk pembuatan tahun 90-an tidak dapat diterima) dan konfigurasi relatif mengganggu.

Kami perlahan tapi pasti memindahkan sebagian besar repo ke CirlceCI dan sangat senang dengan itu. Antrian benar-benar cepat dan adil, dan konfigurasinya relatif mudah.

Juga mendengar hal-hal hebat tentang Bitrise dalam pengertian itu.

Sangat memalukan tentang BB, menarik untuk mengawasinya karena saya tidak berpikir Apple akan membunuhnya - tapi ya

Memiliki pengalaman dengan versi Jenkins yang lebih lama, sebagai alat itu pasti mampu tetapi akan membutuhkan cukup banyak pemeliharaan/konfigurasi dan dalam seni menjaga segala sesuatunya tetap terbuka dan kolaboratif mungkin bukan yang terbaik dengan jujur

Juga jika kita mencari penyedia "besar" lain, kita menghadapi risiko yang sama hanya disapu oleh perusahaan lain yang bermain Monopoli

Saya akan cenderung untuk mencoba Bitrise, 2 sen saya

Saya jelas bias ;) tetapi hal seperti ini tidak akan terjadi dengan App Center.
Silakan hubungi jika Anda tertarik.

cc @Palleas

_{Dikirim dengan GitHawk}

Https://Buildozer.io mendukung iOS dan Android. (pengungkapan: Saya salah satu pendirinya)

Kami telah menggunakan CircleCI di semua proyek Artsy iOS yang memerlukan mac untuk CI - antrian OSS tidak menjadi masalah seperti travis'

Saya menghabiskan sepanjang hari mencoba Bitrise dan App Center. Sejauh ini, mereka tidak terlihat mudah digunakan dan ajaib seperti yang dilakukan BuddyBuild...
Saya senang untuk tim BB (dan bangga karena saya juga di Vancouver) tetapi sangat kesal sebagai pengguna ...
BuddyBuild adalah salah satu layanan yang hanya berfungsi, hampir tidak memerlukan konfigurasi.

Saya sangat menyukai cara kerja Buddybuild. Saya sudah lelah dengan Circle CI sebelumnya tetapi ada beberapa hal yang perlu diperhatikan di sini adalah ia menggunakan Fastlane untuk menandatangani dan menyebarkan ke Uji Penerbangan, Penandatanganan Otomatis tidak dapat digunakan. harus menggunakan "Manual"

Saya menyiapkan waktu untuk mengobrol dengan @TroubleMakerBen , AppCenter _terlihat_ sangat bagus. Akan mempelajari lebih lanjut tentang itu dan melaporkan kembali!

Periksa https://buildkite.com/ mereka menawarkan akun gratis untuk OSS

Penggemar berat bitrise di sini. Kami sering menggunakannya dengan solusi kami https://www.appaloosa-store.com/

@sregg apa yang sebenarnya tidak berfungsi untuk Anda di App Center? Saya akan dengan senang hati membantu dengan apa pun yang spesifik untuk Build.

@derpixeldan misalnya, integrasi Slack semuanya manual menggunakan webhook dibandingkan dengan hanya kotak centang dengan BB. Juga, tidak ada cara untuk memulai nomor build dari nomor tertentu (yaitu nomor build saya saat ini di BB). Akhirnya, menandatangani aplikasi iOS tidak terlihat semudah BB (saya pikir saya hanya memberi mereka nama pengguna/kata sandi id Apple saya dan mereka mengelola sertifikat dan penyediaan secara otomatis)

Saya manajer teknik di Microsoft untuk App Center Build. Kami memiliki tim hebat yang melakukan peningkatan setiap minggu dan kami berkomitmen untuk dukungan multi-platform.

@sregg umpan balik yang bagus dan saya pikir peningkatan di semua area itu ada di simpanan kami.

Juga jangan ragu untuk DM saya di Twitter di https://twitter.com/0xlukekim dengan masalah/masalah/umpan balik apa pun.

Saya harus mengatakan bahwa saya sangat terkesan dengan App Center terutama dalam arti "meta" dari:

• Upaya pengembangan yang dilakukan Microsoft ke dalamnya.
• Kepemilikan dan kepedulian beberapa karyawan ditunjukkan dengan berkomentar di sini.
• Saya telah melihatnya beraksi di AltConf tahun lalu dan tampaknya cukup bagus.

Tidak memiliki pengalaman yang cukup dengan itu, tetapi sepertinya pesaing yang layak juga :)

Hai semuanya, saya Viktor dari https://www.bitrise.io (CTO & Co-founder).

Terima kasih semua orang untuk rekomendasi, itu berarti banyak untuk tim kami!

Hanya ingin menyapa dan memastikan Anda bahwa kami tentu saja mendengarkan, jangan ragu untuk melakukan ping kepada kami kapan saja melalui salah satu saluran dukungan kami dan saya juga akan dengan senang hati menjawab pertanyaan apa pun yang Anda miliki di sini!

Haha, saya pikir kita bisa memulai perang penawaran sekarang

GitHawk saya membawa semua CI ke halaman

Ada juga https://buddy.works Saya tidak menggunakan layanan mereka, jadi sulit untuk mengatakan apakah mereka bagus. Mereka memiliki nama yang keren pasti ;P

Saya pindah dari BuddyBuild ke Bitrise (kami benar-benar menginginkan satu tempat untuk iOS dan Android kami). Memang perlu membaca dokumen dan juga beberapa repo git langkah, tetapi berjalan cukup lancar, membutuhkan waktu sekitar satu hari bersama melakukan hal-hal lain.

@sregg Sekedar menyebutkan kami menggunakan langkah "Sesuaikan BuildNumber" ke += 640, karena kami menggunakannya untuk versionCode dan secara otomatis menyebarkan dari BB.

Perbedaan utama yang saya temukan dengan Bitrise daripada BuddyBuild (selain dari hampir semua yang berbasis GUI di BB) adalah untuk membagi pembangunan Gradle menjadi beberapa langkah. BuddyBuild akan (mungkin lebih efisien) membangun semua yang Anda minta dan kemudian mengeluarkan hal-hal yang relevan untuk mengatakan email penyebaran atau penerbitan ke Play Store, dengan Bitrise Anda memiliki beberapa pilihan yang bisa saya lihat: 1. membaginya menjadi beberapa langkah Build/Gradle, misalnya untuk Pengujian UI/Android, untuk build pengujian Anda [2x3=6 varian untuk kami], satu untuk artefak penerapan App/Play Store Anda, dengan beberapa langkah pembersihan di antaranya (misalnya, saya mengubah folder penerapan setelah ke mencegah email keluar di tempat filter tidak mencukupi)... atau 2. merasa nyaman dengan skrip bash dan memiliki langkah skrip yang membagi variabel ENV peta-pipa sehingga dapat digunakan dengan lebih mudah di langkah selanjutnya.

Akan lebih baik untuk memiliki lebih banyak contoh, mengatur pesan slack untuk menyertakan sesuatu seperti yang dikirim oleh BB secara default misalnya bagus untuk dapat menyesuaikan tetapi umumnya kami hanya ingin kembali menulis kode.

Yang lainnya adalah fitur yang tidak kami gunakan, manajemen penguji (kami menggunakan Play Store Alpha dan TestFlight), dan shake for crash / crash logger (kami lebih suka Firebase).

Salah satu fitur yang sangat keren adalah tidak hanya dapat melihat dan mengedit alur kerja Anda sebagai file .yml, tetapi juga mengunduh dan menjalankannya secara lokal dengan CLI.

Sejujurnya itu lebih banyak pekerjaan daripada yang biasa kita lakukan, itulah gunanya membayar bulanan kan? Tapi itu hanya satu kali dan bonusnya adalah kemampuan penyesuaian ekstra. Secara keseluruhan meskipun itu melakukan pekerjaan dengan sangat baik, dan dengan harga yang bagus. Saya senang dengan sakelar ini. Saya yakin CircleCI juga bagus (kami menggunakannya untuk back-end kami).

Perlu juga dicatat, seluruh infra bitrise adalah OSS - https://github.com/bitrise-io/bitrise.io

Terima kasih @richardleggett atas umpan baliknya, saya akan mendiskusikan ini dengan tim!

Terutama yang Slack - Saya pikir itu sudah lama tertunda sekarang untuk memiliki pesan default "lebih menarik" (lebih berguna) di sana, alih-alih mengharuskan Anda untuk membuat pesan "impian" Anda tepat setelah menjatuhkan langkah pertama kali. Fleksibilitas itu penting, tetapi begitu juga nilai default / pengalaman pengaturan (dan kecepatan). Anda dapat mengubah pesan setelah itu, jadi tidak ada masalah dengan membuat default lebih bertele-tele.

Gradle: akan mendiskusikannya dengan tim perkakas juga, terima kasih telah menyoroti!

Saya telah menendang kaleng ini (perlahan meningkatkan kecemasan saya). Ingin menautkan ke posting blog ini menjelajahi alternatif jika ada info lebih lanjut di sana.

Saya ingin meluangkan waktu bersama @orta dan @krausefx saat berada di kota untuk mendiskusikan visi "bintang utara" saya untuk mengotomatisasi proyek ini (di luar CI). Akan melaporkan kembali setelah saya mengumpulkan energi untuk benar-benar mengerjakan ini.

Terima kasih atas pembaruan di @rnystrom ini. Saya mengerti perasaanmu. 😕

@rnystrom terima kasih atas posting blog dan maaf mendengar Anda mengalami masalah dengan menyiapkan distribusi di bitrise. Tidak yakin apakah Anda melihatnya, tetapi sekarang kami telah membuat Penyediaan Otomatis untuk penandatanganan kode, yang setelah dikonfigurasi dapat mengelola file penandatanganan iOS untuk Anda secara otomatis: https://blog.bitrise.io/ios-auto-provision-step

Bagaimanapun, hanya ingin mengucapkan terima kasih telah mencoba bitrise, dan untuk memberi tahu Anda bahwa kami selalu senang membantu, jika Anda ingin mencoba bitrise lagi. Silakan ping saya di mana saja, misalnya di Slack kami (http://chat.bitrise.io).

@viktorbenei Untuk apa nilainya, itu bukan posting blog Ryan!

Aduh, astaga, ini masih cukup pagi di sini Maaf tuan-tuan dan terima kasih @Sherlouk !

Sebenarnya memulai pekerjaan Bitrise tadi malam. Akan melaporkan kembali!

_{Dikirim dengan GitHawk}

Bangunan bitris berwarna hijau! Semudah setup seperti BB. Saya pikir kami memiliki pemenang.

_{Dikirim dengan GitHawk}

Senang mendengar @rnystrom ! :)

Memang, pengaturan awal harus cukup halus, mirip dengan BB. Perbedaan utama adalah konfigurasi UI setelah itu. Pendekatan BB adalah untuk menyediakan UI sederhana, yang menyiratkan bahwa hal-hal tertentu mungkin tidak mungkin / tidak dapat diubah, sementara kami berfokus terutama pada fleksibilitas, untuk memungkinkan Anda menentukan setiap aspek proses jika Anda suka (tetapi ini disertai dengan kompleksitas & kurva belajar yang lebih curam). Kami tahu bahwa kurva pembelajaran ini mungkin terlalu banyak terutama untuk proyek hobi dan kami sedang berusaha memperbaikinya; beberapa hal yang direncanakan untuk tahun ini untuk membuat penyebaran dll. konfigurasi lebih mudah ;)

https://appcenter.ms tampaknya menjanjikan

Atas nama transparansi, inilah posisi kami saat ini: Saya memiliki Bitrise dan App Center CI yang membangun GitHawk. Kedua layanan tersebut cukup mudah digunakan, jadi saya ingin mencoba menggunakan keduanya untuk memberikan beberapa versi beta dan satu versi App Store, yang mendokumentasikan proses saya.

Inilah pemikiran awal saya

Bitris

kelebihan

• Dukungan yang luar biasa (h/t @viktorbenei)
• Pembuatan cukup cepat
• Terapkan melalui fastlane
• Kustomisasi ekstrim & perincian langkah-langkah pembuatan
• Platform adalah open source (ish)
• Dorong build ke ITC secara otomatis dari master (Saya _suka_ ini)

Kontra

• Tidak ada paket gratis sumber terbuka (_yet_)
• Startup (bisa diperoleh atau hilang)

Pusat Aplikasi

kelebihan

• Pembuatannya _sangat_ cepat
• Lebih sedikit penyesuaian = lebih banyak perampingan
• Disesuaikan untuk penerapan iOS/Android
• @TroubleMakerBen batu
• Didukung oleh Microsoft
  
  
  
  • Mungkin tidak akan segera pergi
  
  
  • ++sumber daya
  
  

Kontra

• Tidak ada paket gratis sumber terbuka (_yet_)
• Membutuhkan target bersama untuk membangun
• tbd penyebaran otomatis (mengkonfirmasi kedatangannya)
• Terlalu banyak barang yang tidak akan kami gunakan (mis. Saya tidak memerlukan SDK Pusat Aplikasi)
• Keluaran log _sangat bertele-tele_, sulit untuk menemukan kesalahan pembuatan
• Tidak ada integrasi status GitHub

Terima kasih telah berbagi @rnystrom ! Hanya satu koreksi, komponen layanan web bitrise bukan open source, jadi tidak mungkin untuk menghosting sendiri API & UI web (belum;). Semua alat yang digunakan untuk menjalankan konfigurasi (editor alur kerja, runner CLI, ...) adalah open source, sehingga Anda dapat mengunduh konfigurasi build dan menjalankannya di Mac Anda sendiri (atau di Mac/Linux apa pun), mirip dengan jalur cepat.

Hanya sebuah pertanyaan, demi perbandingan

Bitrise: Kekurangan: Tidak ada paket gratis open source (belum)

Apakah AppCenter memiliki paket sumber terbuka? Mungkin melewatkannya, AFAIK mereka juga tidak memilikinya. Saya benar-benar hanya ingin tahu karena tidak dapat menemukan apa pun yang terkait di situs web appcenter.

Tidak ada integrasi status GitHub

Itu besar ️

@viktorbenei akan memperbarui! Belum juga

_{Dikirim dengan GitHawk}

Hai semuanya,

Thx atas feedback dan perbandingannya. Saya suka itu dan PM kami melihat utas ini.

tbd penyebaran otomatis (mengkonfirmasi kedatangannya)

Saat ini kami sedang bekerja keras untuk membuat Distribusi lebih baik. Pantau terus.

Apakah AppCenter memiliki paket sumber terbuka? Mungkin melewatkannya, AFAIK mereka juga tidak memilikinya. Saya benar-benar hanya ingin tahu karena tidak dapat menemukan apa pun yang terkait di situs web appcenter.

Kami belum memiliki rencana OSS.

Semangat semuanya dan selamat berakhir pekan!

Ini mungkin relevan sekarang https://github.com/fastlane/ci 👍

@KrauseFx Saya telah melihat ini dan saya sangat bersemangat tentang hal itu.

Mengapa meminta fitur jika kita sebagai komunitas dapat membangunnya? Plus, Google mendukung ini? tidak bisa meminta lebih banyak.

Sangat menantikan untuk memberikan kontribusi kode untuk ini saat ini berkembang dan menerapkannya ke alur kerja kami saat matang.

Terima kasih untuk semua yang kalian lakukan untuk komunitas!

@KrauseFx pemain 3 telah memasuki permainan

_{Dikirim dengan GitHawk}

lolz

Saya tidak berpikir pusat aplikasi mendukung per komit [ci skip] seperti sintaks

@dkhamsing sayangnya tidak (belum).

Satu plus nyata untuk buddybuild yang saya sukai adalah cara mereka menunjukkan sebelum/sesudah/berbeda dalam hasil pengujian jika pengujian unit FBSnapshotTestCase menghasilkan gambar yang tidak terduga.

Adakah yang tahu jika salah satu dari sistem lain ini memiliki fitur serupa?

Apakah App Center mendukung pembangunan dari permintaan tarik?? Saya sangat bingung cc @TroubleMakerBen

@dkhamsing memang!

edit: sudahlah

_{Dikirim dengan GitHawk}

@dkhamsing App Center mendukung build on PUSH, tetapi belum build on PR (build on merge), belum.

Ah aku mengerti. Thx Ryan, Ben

_{Dikirim dengan GitHawk}

Setelah membaca utas ini, tampaknya menjadi perlombaan dua kuda: Bitris dan Pusat Aplikasi. Namun tidak ada yang menyentuh subjek tes UI: Saya menyukai bagaimana di BB, hanya dengan beberapa klik, Anda dapat menjalankan tes espresso di perangkat virtual. Apakah salah satu dari dua platform yang sedang dibahas mendukung ini?

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

_{Dikirim dengan GitHawk}

@dkhamsing App Center Test sebenarnya menjalankan Tes UI pada perangkat fisik – kami memiliki beberapa ribu. Tidak, Anda tidak dapat melihat gambar;)

Kami sebenarnya mencoba mengidentifikasi solusi CI baru.

• AppCenter : mirip dengan bb tetapi tidak memberikan dukungan PR, saya pikir lebih fokus kepada orang-orang manajemen, juga log tidak menyediakan tumpukan jika ada tugas yang gagal.

• Bitrise: Sangat dapat dikonfigurasi, menawarkan banyak "langkah" terbuka seperti cakupan kode, menyebarkan, menandatangani, unitTest, UITest, membangun, mengirimkan, membersihkan dan kustom, karena Anda memiliki kemampuan untuk mengonfigurasinya, hanya sedikit bingung dengan file .yaml, Anda dapat memicu langkah-langkah yang diberikan Push, PR, dll

• Nevercode Sangat dapat dikonfigurasi, Anda dapat memilih antara tugas bertahap per cabang, membangun PR, tanpa paket gratis.

Saya pikir setidaknya Bitrise menawarkan banyak fitur yang dapat kita manfaatkan!

Dari tautan yang diposting di atas tentang pengujian di App Center

1. Tinjau konsep inti
   Memahami konsep inti pengalaman Test Cloud meningkatkan kemudahan penggunaan, navigasi, dan komunikasi dengan dukungan. Disarankan untuk membiasakan diri dengan konsep-konsep ini sebelum menjalankan tes pertama Anda.

Apa-apaan... Saya tidak ingin meninjau konsep apa pun, inti atau lainnya, saya hanya ingin itu berfungsi dengan 2 klik seperti yang dilakukan di BB :( Saya tidak punya 10 jam untuk tenggelam dalam membuat ini bekerja, Saya seorang pembuat kode bukan insinyur devops ...

Ya, dokumentasi Pusat Aplikasi dapat disederhanakan

_{Dikirim dengan GitHawk}

@acristescu

Setelah membaca utas ini, tampaknya menjadi perlombaan dua kuda: Bitris dan Pusat Aplikasi. Namun tidak ada yang menyentuh subjek tes UI: Saya menyukai bagaimana di BB, hanya dengan beberapa klik, Anda dapat menjalankan tes espresso di perangkat virtual. Apakah salah satu dari dua platform yang sedang dibahas mendukung ini?

Tidak (belum) satu klik tetapi juga lebih kuat dalam beberapa cara: https://blog.bitrise.io/introducing-solid-and-snappy-virtual-device-testing-for-android

Kami sedang berupaya membuat penyiapan lebih mudah (itulah sebabnya ini masih "beta", bukan karena kurangnya fungsionalitas ;)).

@acristescu @dkhamsing Kami sadar! Jauhkan umpan balik yang datang.

@viktorbenei Saya akan mencoba tetapi oh Tuhan gaya seni itu tidak menyenangkan. Aku ingat kenapa aku menjauh dari Bitrise di masa lalu... awan yang tersenyum saling berpelukan? Hiu dengan laser diikat ke mereka?!? Tombol hijau di atas latar belakang ungu cerah? Mungkin saya hanya menunjukkan usia saya di sini, tetapi bagaimana saya bisa merekomendasikan alat ini kepada klien yang... katakanlah... bank?

Tidak masalah @acristescu , saya pasti mengerti maksud Anda, umpan balik yang jujur ​​​​selalu diterima dan pembaruan desain sudah dalam pengerjaan ;)

Saya memutuskan untuk mencoba keduanya dengan repo sederhana ( https://github.com/acristescu/GreenfieldTemplate ) dan melihat di mana saya sampai. Sejauh ini saya sudah mencoba App Center dan menemukan beberapa hambatan:

• dipecahkan (tidak dapat menemukan alat pembuatan gradle!), Anda harus menambahkan repositori google() secara manual ke gradle proyek Anda
• itu memulai kembali nomor build dari 1 sedangkan saya sudah merilis di play store a 42, google hanya akan menolak build!)
• Saya tidak dapat menemukan cara menguji perangkat virtual secara gratis, hanya pada perangkat nyata dengan uji coba gratis 30 hari .
• Saya tidak yakin itu menjalankan tes unit karena

##[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.

Tidak yakin tentang apa itu...

Bitrise: Di sisi positifnya, pengaturannya sama tidak menyakitkannya meskipun saya pikir jika saya perlu mengubah apa pun, saya perlu membuka file yml dan mengutak-atiknya (pembaruan: menemukan sesuatu yang disebut editor alur kerja. terlihat menakutkan tetapi kuat) . Halangan:

• itu tidak pernah bertanya kepada saya varian mana yang harus dibuat dan memilih yang salah. Saya ingin prodRelease tetapi untuk alasan apa pun itu memutuskan untuk membangun persis dua mockDebug dan prodDebug . Tidak dapat menemukan tempat untuk mengubahnya, tetapi saya cukup yakin pasti ada.
• build membutuhkan waktu lebih lama, 4 menit, bukan 2 menit 16 untuk pusat aplikasi. Ini mungkin karena masalah di atas?
• tidak melihat penyebutan tes junit di mana pun di log. Aku ragu itu menjalankan mereka. Tidak jelas cara menambahkannya, mungkin di suatu tempat di editor alur kerja? (pembaruan bermain-main dengan Editor Alur Kerja selama sekitar 10 menit dan menemukannya. Poin bonus karena memungkinkan saya kebebasan untuk memilih target test akan dijalankan)
• tidak yakin build ID apa yang digunakan, bagaimana cara melihatnya?

Thx untuk posting ini

_{Dikirim dengan GitHawk}

Terima kasih @acristescu atas umpan balik terperinci, kami sangat menghargainya. Terutama pada peringatan untuk file laporan pengujian JUnit di App Center, ini tidak memengaruhi uji coba Anda yang sebenarnya dan harus segera diperbaiki.
Tetap datang!

Butuh waktu dua jam tetapi saya berhasil meyakinkan pusat aplikasi untuk mengunggah ke google play. Namun, sepertinya saya tidak dapat meyakinkannya untuk melakukan ini secara otomatis, saya harus mengunduh APK yang ditandatangani dari pusat aplikasi dan kemudian mengunggahnya kembali ke bagian penyebaran/penyimpanan (!) untuk membuatnya berfungsi. Tampaknya sangat berbelit-belit, apa yang saya lakukan salah?

PS: Untuk menambahkan penghinaan pada cedera, BuddyBuild dikerahkan beberapa kali dalam rentang waktu yang sama karena saya lupa menonaktifkannya di awal dan itu hanya bekerja secara otomatis tanpa campur tangan manusia ...

Hai @acristescu ,

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

itu tidak pernah bertanya kepada saya varian mana yang harus dibuat dan memilih yang salah. Saya ingin prodRelease tetapi untuk alasan apa pun itu memutuskan untuk membangun dua mockDebug dan prodDebug lainnya. Tidak dapat menemukan tempat untuk mengubahnya, tetapi saya cukup yakin pasti ada.

Memang pemindai kami saat ini akan menambahkan langkah Gradle Runner, dengan assembleDebug dikonfigurasi untuk alur kerja dasar. Kami menyadari bahwa ini mungkin tidak cukup mudah, tetapi singkatnya jika Anda ingin membangun prodRelease maka tugas gradle adalah assembleProdRelease . Jika Anda ingin menjalankan lint maka tugas gradle adalah lint . Anda dapat melakukan semua ini dengan langkah Gradle Runner, sebenarnya gradle dapat menangani banyak tugas sehingga untuk menjalankan lint dan kemudian assembleProdRelease Anda juga dapat menetapkan ini sebagai tugas: lint assembleProdRelease yang akan melakukan keduanya.

Kami sedang mengerjakan langkah-langkah baru & konfigurasi default pemindai baru yang akan mempermudah ini, dengan langkah-langkah yang lebih spesifik (misalnya langkah "Lint" yang menjalankan tugas lint gradle, alih-alih mengharuskan Anda menyetel tugas itu di langkah "Pelari Gradle")

build membutuhkan waktu lebih lama, 4 menit, bukan 2 menit 16 untuk pusat aplikasi. Ini mungkin karena masalah di atas?

Memang tampaknya demikian, karena assembleDebug kemungkinan besar menghasilkan 2 APK/varian terpisah dalam kasus Anda alih-alih satu "ProdRelease".

tidak melihat penyebutan tes junit di mana pun di log. Aku ragu itu menjalankan mereka.

Tentukan test sebagai input tugas gradle dari langkah Gradle Runner, yang akan menjalankan pengujian Anda - atau tambahkan langkah Gradle Unit Test yang dikonfigurasi untuk menjalankan tugas gradle tersebut secara default.

tidak yakin build ID apa yang digunakan, bagaimana cara melihatnya?

Jika maksud Anda apakah kami menyetel nomor build ke bitrise.io build number: secara default kami tidak melakukannya, Anda dapat melakukannya dengan menambahkan langkah Change Android versionCode dan versionName misalnya.

Sekali lagi terima kasih atas umpan balik Anda, kami mendengarkan & sudah dijadwalkan untuk meningkatkan poin pengalaman penyiapan ini! ;)

Diskusi yang luar biasa. Saya kesulitan menemukan alternatif BuddyBuild yang mendukung Carthage.

Saya melihat ke Nevercode, mereka hanya mendukung cocoapods.

Saya percaya pusat Aplikasi mendukung Carthage.

Ada yang lain?

@jamesone

Saya pikir opsi terbaik untuk Anda adalah Bitrise, mereka menyediakan platform seperti pipa bitbucket , Anda juga dapat mengonfigurasi berdasarkan kebutuhan Anda menggunakan Langkah.

Sebenarnya kami pindah dari bb ke bitrise, kami menggunakan Android dan iOS dan semuanya sempurna!

Luar biasa @cbedoy Apa yang Anda lakukan dengan build yang dapat diinstal yang disediakan buddybuild untuk semua cabang Anda? Apakah Bitrise memiliki integrasi ATAU dukungan untuk ini?

Anda dapat memicu alur kerja (banyak _langkah_) saat Anda mendorong, membuat PR, atau tag.

Anda juga dapat menjadwalkan pembangunan per cabang.

Anda harus memeriksa:

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

Ketika Anda memahami bagaimana bitrise bekerja dapat membuat alur kerja berdasarkan apa yang Anda butuhkan, yaitu saya ingin alur kerja di mana hanya menjalankan unitTesting jika seseorang membuat PR atau saya ingin alur kerja di mana membangun dan menghasilkan .ipa ketika master ditandai.

Bitrise adalah sesuatu seperti gambar buruh pelabuhan di mana Anda dapat memilih _steps_ pihak ketiga untuk menjalankan unitTest, CodeCoverage, atau Archive dan menyebarkan.

Pria yang luar biasa! Kedengarannya sangat menarik. Aku akan melihat ke dalamnya.