🧘🏽 🤜🏿 👔 अपने कोटलिन मल्टीप्लायटरी लाइब्रेरी के लिए सतत वितरण 🦔 🤟🏼 👨🏾‍🎓

लोगो

नमस्ते! मेरा नाम यूरी व्लाद है, मैं Badoo पर एक एंड्रॉइड डेवलपर हूं और शुद्ध कोटलिन पर रेकिटिव लाइब्रेरी - रिएक्टिव एक्सटेंशन्स बनाने में भाग लेता हूं ।

इस प्रक्रिया में, हमें इस तथ्य का सामना करना पड़ रहा है कि कोटलिन मल्टीप्लायर के मामले में निरंतर एकीकरण और निरंतर वितरण के लिए अतिरिक्त कॉन्फ़िगरेशन की आवश्यकता होती है। पूरी तरह से पुस्तकालय को इकट्ठा करने के लिए विभिन्न ऑपरेटिंग सिस्टम पर कई वर्चुअल मशीनें होना आवश्यक है। इस लेख में मैं दिखाऊंगा कि आपके कोटलिन मल्टीप्लाय्ट्री लाइब्रेरी के लिए निरंतर वितरण कैसे कॉन्फ़िगर करें।

ओपन-सोर्स पुस्तकालयों के लिए निरंतर एकीकरण और निरंतर वितरण

निरंतर एकीकरण और निरंतर वितरण लंबे समय से विभिन्न सेवाओं के लिए खुले स्रोत समुदाय का एक हिस्सा रहा है। उनमें से कई मुक्त करने के लिए ओपन-सोर्स प्रोजेक्ट्स के लिए अपनी सेवाएं प्रदान करते हैं: ट्रैविस सीआई, जीटपैक, सर्किलसीआई, माइक्रोसॉफ्ट एज़्योर पाइपलाइन, हाल ही में लॉन्च किए गए गिटहब एक्शन।

Android के लिए Badoo के ओपन-सोर्स प्रोजेक्ट्स में, हम निरंतर एकीकरण के लिए ट्रैविस CI और निरंतर डिलीवरी के लिए JitPack का उपयोग करते हैं।

हमारे बहु-प्लेटफ़ॉर्म लाइब्रेरी में iOS समर्थन को लागू करने के बाद, मैंने पाया कि हम JitPack का उपयोग करके लाइब्रेरी का निर्माण नहीं कर सकते हैं, क्योंकि यह macOS पर वर्चुअल मशीन प्रदान नहीं करता है (iOS केवल macOS पर बनाया जा सकता है)।

इसलिए, पुस्तकालय के आगे प्रकाशन के लिए, बिंट्रे , जो सभी के लिए अधिक परिचित थे, को चुना गया था। यह JitPack के विपरीत प्रकाशित कलाकृतियों की महीन ट्यूनिंग का समर्थन करता है, जो कि publishToMavenLocal कॉल के सभी परिणामों को publishToMavenLocal ।

प्रकाशन के लिए, ग्रैडल बिंट्रे प्लगिन का उपयोग करने की सिफारिश की जाती है, जिसे मैंने बाद में अपनी आवश्यकताओं के लिए अनुकूलित किया। और परियोजना का निर्माण करने के लिए, मैंने कई कारणों से ट्रैविस सीआई का उपयोग करना जारी रखा: सबसे पहले, मैं पहले से ही इससे परिचित था और लगभग सभी पालतू परियोजनाओं में इसका इस्तेमाल करता था; दूसरे, यह iOS पर बनाने के लिए आवश्यक macOS वर्चुअल मशीन प्रदान करता है।

एक बहु मंच पुस्तकालय के समानांतर विधानसभा

यदि आप कोटलिन प्रलेखन के आंत्र में बहते हैं, तो आप बहु-मंच पुस्तकालयों के प्रकाशन पर एक अनुभाग पा सकते हैं।

कोटलिन मल्टीप्लायर के डेवलपर्स मल्टी-प्लेटफॉर्म असेंबली की समस्याओं से अवगत हैं (हर चीज किसी भी ऑपरेटिंग सिस्टम पर नहीं बनाई जा सकती है) और अलग-अलग ऑपरेटिंग सिस्टम पर अलग से लाइब्रेरी बनाने की पेशकश करते हैं।

 kotlin { jvm() js() mingwX64() linuxX64() // Note that the Kotlin metadata is here, too. // The mingwx64() target is automatically skipped as incompatible in Linux builds. configure([targets["metadata"], jvm(), js()]) { mavenPublication { targetPublication -> tasks.withType(AbstractPublishToMaven) .matching { it.publication == targetPublication } .all { onlyIf { findProperty("isLinux") == "true" } } } } }

जैसा कि आप ऊपर दिए गए कोड से देख सकते हैं, isLinux पारित isLinux संपत्ति के आधार पर, हम कुछ लक्ष्यों isLinux प्रकाशन को isLinux हैं। भविष्य में लक्ष्य के तहत मैं एक विशिष्ट मंच के लिए विधानसभा का मतलब करूंगा। विंडोज पर, केवल विंडोज का लक्ष्य एकत्र किया जाएगा, जबकि अन्य ऑपरेटिंग सिस्टम पर मेटाडेटा और अन्य लक्ष्य एकत्र किए जाएंगे।

एक बहुत ही सुंदर और संक्षिप्त समाधान जो केवल publishToMavenLocal लिए काम करता है या publishToMavenLocal maven-publish प्लगइन maven-publish होता है, जो ग्रैडल बिंट्रे प्लगिन के उपयोग के कारण हमारे लिए उपयुक्त नहीं है।

मैंने लक्ष्य का चयन करने के लिए पर्यावरण चर का उपयोग करने का निर्णय लिया, क्योंकि यह कोड पहले ग्रूवी में लिखा गया था, एक अलग ग्रूवी ग्रैड लिपि में रखना और पर्यावरण चर तक पहुंच एक स्थिर संदर्भ से है।

 enum class Target { ALL, COMMON, IOS, META; val common: Boolean @JvmName("isCommon") get() = this == ALL || this == COMMON val ios: Boolean @JvmName("isIos") get() = this == ALL || this == IOS val meta: Boolean @JvmName("isMeta") get() = this == ALL || this == META companion object { @JvmStatic fun currentTarget(): Target { val value = System.getProperty("MP_TARGET") return values().find { it.name.equals(value, ignoreCase = true) } ?: ALL } } }

हमारी परियोजना के हिस्से के रूप में, मैंने लक्ष्य के चार समूहों की पहचान की:

सभी - सभी लक्ष्य जुड़े हुए हैं और एकत्र किए जाते हैं, विकास के लिए और डिफ़ॉल्ट मान के रूप में उपयोग किए जाते हैं।
COMMON - केवल लिनक्स-संगत लक्ष्य जुड़े और एकत्र किए जाते हैं। हमारे मामले में, ये जावास्क्रिप्ट, JVM, Android JVM, Linux x64 और Linux ARM x32 हैं।
IOS - केवल iOS लक्ष्य जुड़े और एकत्र किए जाते हैं, इसका उपयोग macOS पर असेंबली के लिए किया जाता है।
मेटा - सभी लक्ष्य जुड़े हुए हैं, लेकिन केवल ग्रेड मेटाडेटा के लिए मेटा-जानकारी वाले मॉड्यूल को इकट्ठा किया जाता है।

लक्ष्य समूहों के इस सेट के साथ, हम प्रोजेक्ट की असेंबली को तीन अलग-अलग वर्चुअल मशीनों (COMMON - Linux, IOS - macOS, META - Linux) में समांतर कर सकते हैं।

फिलहाल, आप सब कुछ macOS पर बना सकते हैं, लेकिन मेरे समाधान के दो फायदे हैं। सबसे पहले, अगर हम विंडोज के लिए समर्थन लागू करने का निर्णय लेते हैं, तो हमें इसे बनाने के लिए विंडोज पर एक नया लक्ष्य समूह और एक नई वर्चुअल मशीन जोड़ने की जरूरत है। दूसरे, लिनक्स पर वर्चुअल मशीन संसाधनों को खर्च करने की आवश्यकता नहीं है जो आप लिनक्स पर बना सकते हैं। ऐसी वर्चुअल मशीनों पर सीपीयू का समय आमतौर पर दोगुना महंगा होता है।

ग्रेडेड मेटाडेटा

ग्रेडेड मेटाडाटा क्या है और इसके लिए क्या है?

मावेन वर्तमान में निर्भरता को हल करने के लिए पीओएम (प्रोजेक्ट ऑब्जेक्ट मॉडल) का उपयोग करता है।

 <?xml version="1.0" encoding="UTF-8"?> <project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <modelVersion>4.0.0</modelVersion> <groupId>com.jakewharton.rxbinding2</groupId> <artifactId>rxbinding-leanback-v17-kotlin</artifactId> <version>2.2.0</version> <packaging>aar</packaging> <name>RxBinding Kotlin (leanback-v17)</name> <description>RxJava binding APIs for Android's UI widgets.</description> <url>https://github.com/JakeWharton/RxBinding/</url> <licenses> <license> <name>The Apache Software License, Version 2.0</name> <url>http://www.apache.org/licenses/LICENSE-2.0.txt</url> <distribution>repo</distribution> </license> </licenses> <developers> <developer> <id>jakewharton</id> <name>Jake Wharton</name> </developer> </developers> <scm> <connection>scm:git:git://github.com/JakeWharton/RxBinding.git</connection> <developerConnection>scm:git:ssh://git@github.com/JakeWharton/RxBinding.git</developerConnection> <url>https://github.com/JakeWharton/RxBinding/</url> </scm> <dependencies> <dependency> <groupId>com.android.support</groupId> <artifactId>support-annotations</artifactId> <version>28.0.0</version> <scope>compile</scope> </dependency> </dependencies> </project>

POM फ़ाइल में लाइब्रेरी संस्करण, इसके निर्माता और आवश्यक निर्भरता के बारे में जानकारी होती है।

लेकिन क्या होगा अगर हम अलग-अलग JDK के लिए लाइब्रेरी के दो संस्करण चाहते हैं? उदाहरण के लिए, kotlin-stdlib के दो संस्करण हैं: kotlin-stdlib-jdk8 और kotlin-stdlib-jdk7 । उपयोगकर्ताओं को वांछित संस्करण कनेक्ट करने की आवश्यकता है।

JDK संस्करण को अपग्रेड करते समय, बाहरी निर्भरता के बारे में भूलना आसान है। यह इस समस्या को हल करने के लिए था कि ग्रैडल मेटाडाटा बनाया गया था, जो आपको एक विशेष पुस्तकालय को जोड़ने के लिए अतिरिक्त शर्तों को जोड़ने की अनुमति देता है।

समर्थित org.gradle.jvm.version मेटाडेटा विशेषताओं में से एक org.gradle.jvm.version , जो JDK के संस्करण को इंगित करता है। इसलिए, kotlin-stdlib मेटाडेटा फ़ाइल का सरलीकृत रूप इस तरह दिखाई दे सकता है:

 { "formatVersion": "1.0", "component": { "group": "org.jetbrains.kotlin", "module": "kotlin-stdlib", "version": "1.3.0" }, "variants": [ { "name": "apiElements", "attributes": { "org.gradle.jvm.version": 8 }, "available-at": { "url": "../../kotlin-stdlib-jdk8/1.3.0/kotlin-stdlib-jdk8.module", "group": "org.jetbrains.kotlin", "module": "kotlin-stdlib-jdk8", "version": "1.3.0" } }, { "name": "apiElements", "attributes": { "org.gradle.jvm.version": 7 }, "available-at": { "url": "../../kotlin-stdlib-jdk7/1.3.0/kotlin-stdlib-jdk7.module", "group": "org.jetbrains.kotlin", "module": "kotlin-stdlib-jdk7", "version": "1.3.0" } } ] }

विशेष रूप से, हमारे मामले में, reaktive-1.0.0-rc1.module एक सरलीकृत रूप में इस तरह दिखता है:

 { "formatVersion": "1.0", "component": { "group": "com.badoo.reaktive", "module": "reaktive", "version": "1.0.0-rc1", "attributes": { "org.gradle.status": "release" } }, "createdBy": { "gradle": { "version": "5.4.1", "buildId": "tv44qntk2zhitm23bbnqdngjam" } }, "variants": [ { "name": "android-releaseRuntimeElements", "attributes": { "com.android.build.api.attributes.BuildTypeAttr": "release", "com.android.build.api.attributes.VariantAttr": "release", "com.android.build.gradle.internal.dependency.AndroidTypeAttr": "Aar", "org.gradle.usage": "java-runtime", "org.jetbrains.kotlin.platform.type": "androidJvm" }, "available-at": { "url": "../../reaktive-android/1.0.0-rc1/reaktive-android-1.0.0-rc1.module", "group": "com.badoo.reaktive", "module": "reaktive-android", "version": "1.0.0-rc1" } }, { "name": "ios64-api", "attributes": { "org.gradle.usage": "kotlin-api", "org.jetbrains.kotlin.native.target": "ios_arm64", "org.jetbrains.kotlin.platform.type": "native" }, "available-at": { "url": "../../reaktive-ios64/1.0.0-rc1/reaktive-ios64-1.0.0-rc1.module", "group": "com.badoo.reaktive", "module": "reaktive-ios64", "version": "1.0.0-rc1" } }, { "name": "linuxX64-api", "attributes": { "org.gradle.usage": "kotlin-api", "org.jetbrains.kotlin.native.target": "linux_x64", "org.jetbrains.kotlin.platform.type": "native" }, "available-at": { "url": "../../reaktive-linuxx64/1.0.0-rc1/reaktive-linuxx64-1.0.0-rc1.module", "group": "com.badoo.reaktive", "module": "reaktive-linuxx64", "version": "1.0.0-rc1" } }, ] }

विशेषताएँ org.jetbrains.kotlin के लिए धन्यवाद org.jetbrains.kotlin इस मामले में समझता है कि वांछित स्रोत सेट में खींचने के लिए कौन सी निर्भरता है।

आप मेटाडेटा का उपयोग करके सक्षम कर सकते हैं:

 enableFeaturePreview("GRADLE_METADATA")

आप दस्तावेज़ में विस्तृत जानकारी पा सकते हैं।

सेटिंग प्रकाशित करें

हमने विधानसभा के लक्ष्यों और समानांतरकरण का पता लगाने के बाद, हमें यह कॉन्फ़िगर करने की आवश्यकता है कि हम क्या और कैसे प्रकाशित करेंगे।

प्रकाशन के लिए, हम ग्रैडल बिंट्रे प्लगिन का उपयोग करते हैं, इसलिए पहली बात यह है कि इसके README की ओर मुड़ें और प्रकाशन के लिए हमारी रिपॉजिटरी और क्रेडेंशियल्स के बारे में जानकारी सेट करें।

हम buildSrc फ़ोल्डर में अपने स्वयं के प्लगइन में पूरे कॉन्फ़िगरेशन का प्रदर्शन करेंगे।
buildSrc का उपयोग करना कई फायदे प्रदान करता है, जिसमें एक हमेशा काम करने वाला स्वतः पूर्ण (कोटलिन लिपियों के मामले में, यह अभी भी हमेशा काम नहीं करता है और अक्सर निर्भरता को लागू करने के लिए कॉल की आवश्यकता होती है), इसमें घोषित वर्गों का पुन: उपयोग करने की क्षमता और उन्हें ग्रूवी और कोटलीन लिपियों तक पहुंच प्रदान करना। आप नवीनतम Google I / O (ग्रैगल अनुभाग) से buildSrc का उपयोग करने का एक उदाहरण देख सकते हैं।

 private fun setupBintrayPublishingInformation(target: Project) { //  Bintray Plugin   target.plugins.apply(BintrayPlugin::class) //    target.extensions.getByType(BintrayExtension::class).apply { user = target.findProperty("bintray_user")?.toString() key = target.findProperty("bintray_key")?.toString() pkg.apply { repo = "maven" name = "reaktive" userOrg = "badoo" vcsUrl = "https://github.com/badoo/Reaktive.git" setLicenses("Apache-2.0") version.name = target.property("reaktive_version")?.toString() } } }

मैं परियोजना के तीन गतिशील गुणों का उपयोग करता हूं: bintray_user और bintray_key , जिसे Bintray पर व्यक्तिगत प्रोफ़ाइल सेटिंग्स से प्राप्त किया जा सकता है, और reaktive_version , जो रूट build.gradle फ़ाइल में सेट है।

प्रत्येक लक्ष्य के लिए, कोटलिन मल्टीप्लाक प्लगिन एक MavenPublication बनाता है, जो PublishingExtension में उपलब्ध है।

ऊपर दिए गए कोटलिन प्रलेखन से उदाहरण कोड का उपयोग करते हुए, हम यह कॉन्फ़िगरेशन बना सकते हैं:

 private fun createConfigurationMap(): Map<String, Boolean> { val mppTarget = Target.currentTarget() return mapOf( "kotlinMultiplatform" to mppTarget.meta, KotlinMultiplatformPlugin.METADATA_TARGET_NAME to mppTarget.meta, "jvm" to mppTarget.common, "js" to mppTarget.common, "androidDebug" to mppTarget.common, "androidRelease" to mppTarget.common, "linuxX64" to mppTarget.common, "linuxArm32Hfp" to mppTarget.common, "iosArm32" to mppTarget.ios, "iosArm64" to mppTarget.ios, "iosX64" to mppTarget.ios ) }

इस सरल मानचित्र में हम वर्णन करते हैं कि किसी विशेष वर्चुअल मशीन पर कौन से प्रकाशन जारी किए जाने चाहिए। प्रकाशन का नाम लक्ष्य का नाम है। यह कॉन्फ़िगरेशन पूरी तरह से लक्षित समूहों के विवरण के अनुरूप है जो मैंने ऊपर उद्धृत किया था।

Bintray में प्रकाशन की स्थापना करते हैं। Bintray प्लगइन एक BintrayUploadTask बनाता है, जिसे हम अपनी आवश्यकताओं के अनुसार अनुकूलित करेंगे।

 private fun setupBintrayPublishing( target: Project, taskConfigurationMap: Map<String, Boolean> ) { target.tasks.named(BintrayUploadTask.getTASK_NAME(), BintrayUploadTask::class) { doFirst { //   } } }

हर कोई जो बिंट्रे प्लगइन के साथ काम करना शुरू करता है, उसे जल्दी से पता चलता है कि उसकी रिपॉजिटरी लंबे समय से मॉस के साथ कवर की गई है (आखिरी अपडेट लगभग छह महीने पहले), और यह कि सभी समस्याओं को सभी प्रकार के हैक्स और इश्यू टैब में बैसाखी द्वारा हल किया जाता है। ग्रेडल मेटाडाटा जैसी नई तकनीक के लिए समर्थन को लागू नहीं किया गया था, लेकिन इसी मुद्दे में आप एक समाधान पा सकते हैं जिसका हम उपयोग करते हैं।

 val publishing = project.extensions.getByType(PublishingExtension::class) publishing.publications .filterIsInstance<MavenPublication>() .forEach { publication -> val moduleFile = project.buildDir.resolve("publications/${publication.name}/module.json") if (moduleFile.exists()) { publication.artifact(object : FileBasedMavenArtifact(moduleFile) { override fun getDefaultExtension() = "module" }) } }

इस कोड का उपयोग करते हुए, हम module.json फ़ाइल को प्रकाशन के लिए कलाकृतियों की सूची में जोड़ते हैं, module.json कारण module.json मेटाडाटा काम करता है।

लेकिन हमारी समस्याएं यहीं खत्म नहीं होती हैं। जब आप bintrayPublish चलाने की कोशिश करते हैं bintrayPublish कुछ नहीं होता है।

नियमित जावा और कोटलिन पुस्तकालयों के मामले में, बिंट्रे स्वचालित रूप से उपलब्ध प्रकाशनों को खींचते हैं और उन्हें प्रकाशित करते हैं। हालांकि, कोटलिन मल्टीप्लाट रिकॉर्डर के मामले में, जब स्वचालित रूप से प्रकाशन खींच रहे हैं, तो प्लगइन बस एक त्रुटि के साथ क्रैश हो जाता है। और हां, इसके लिए GitHub पर एक मुद्दा भी है। और हम फिर से समाधान का उपयोग करेंगे, केवल उन प्रकाशनों को फ़िल्टर करके जिनकी हमें आवश्यकता है।

 val publications = publishing.publications .filterIsInstance<MavenPublication>() .filter { val res = taskConfigurationMap[it.name] == true logger.warn("Artifact '${it.groupId}:${it.artifactId}:${it.version}' from publication '${it.name}' should be published: $res") res } .map { logger.warn("Uploading artifact '${it.groupId}:${it.artifactId}:${it.version}' from publication '${it.name}'") it.name } .toTypedArray() setPublications(*publications)

लेकिन यह कोड या तो काम नहीं करता है!

ऐसा इसलिए है क्योंकि bintrayUpload पास आश्रितों में एक कार्य नहीं है जो परियोजना को इकट्ठा करेगा और प्रकाशन के लिए आवश्यक फाइलें बनाएगा। सबसे स्पष्ट समाधान publishToMavenLocal को publishToMavenLocal निर्भरता के रूप में सेट करना है, लेकिन इतना सरल नहीं है।

मेटाडेटा एकत्रित करते समय, हम सभी लक्ष्यों को परियोजना से publishToMavenLocal , जिसका अर्थ है कि publishToMavenLocal सभी लक्ष्यों को संकलित करेगा, क्योंकि इस कार्य के लिए निर्भरता में publishToMavenLocalAndroidDebug , publishToMavenLocalAndroiRelase , publishToMavenLocalJvm आदि शामिल हैं।

इसलिए, हम एक अलग प्रॉक्सी कार्य बनाएंगे, जिसके आधार पर हम केवल उन publishToMavenLocalX को publishToMavenLocalX हैं publishToMavenLocalX हमें आवश्यकता है, और हम इस कार्य को bintrayPublish निर्भरता में स्वयं डाल देंगे।

 private fun setupLocalPublishing( target: Project, taskConfigurationMap: Map<String, Boolean> ) { target.project.tasks.withType(AbstractPublishToMaven::class).configureEach { val configuration = publication?.name ?: run { // Android-       PublishToMaven,        val configuration = taskConfigurationMap.keys.find { name.contains(it, ignoreCase = true) } logger.warn("Found $configuration for $name") configuration } //          enabled = taskConfigurationMap[configuration] == true } } private fun createFilteredPublishToMavenLocalTask(target: Project) { //  -         publishToMavenLocal target.tasks.register(TASK_FILTERED_PUBLISH_TO_MAVEN_LOCAL) { dependsOn(project.tasks.matching { it is AbstractPublishToMaven && it.enabled }) } }

यह केवल सभी कोड को एक साथ इकट्ठा करने और परिणामी प्लग-इन को एक परियोजना में लागू करने के लिए रहता है जिसमें प्रकाशन की आवश्यकता होती है।

 abstract class PublishPlugin : Plugin<Project> { override fun apply(target: Project) { val taskConfigurationMap = createConfigurationMap() createFilteredPublishToMavenLocalTask(target) setupLocalPublishing(target, taskConfigurationMap) setupBintrayPublishingInformation(target) setupBintrayPublishing(target, taskConfigurationMap) }

 apply plugin: PublishPlugin

पूरा PublishPlugin कोड हमारे यहां भंडार में पाया जा सकता है ।

ट्रैविस सीआई को कॉन्फ़िगर करें

सबसे कठिन हिस्सा खत्म हो गया है। यह ट्रैविस CI को कॉन्फ़िगर करने के लिए बना हुआ है ताकि यह विधानसभा को समानांतर बनाए और एक नया संस्करण जारी होने पर बिंट्रे को कलाकृतियों को प्रकाशित कर सके।

हम कमिट पर एक टैग बनाकर नए संस्करण को जारी करेंगे।

 #    ( ) matrix: include: #  Linux  Android  Chrome    JS, JVM, Android JVM  Linux - os: linux dist: trusty addons: chrome: stable language: android android: components: - build-tools-28.0.3 - android-28 #  MP_TARGET,        env: MP_TARGET=COMMON #     install — Gradle     install: true #    JVM       RxJava2 script: ./gradlew reaktive:check reaktive-test:check rxjava2-interop:check -DMP_TARGET=$MP_TARGET #  macOS   iOS- - os: osx osx_image: xcode10.2 language: java env: MP_TARGET=IOS install: true script: ./gradlew reaktive:check reaktive-test:check -DMP_TARGET=$MP_TARGET #  Linux    - os: linux language: android android: components: - build-tools-28.0.3 - android-28 env: MP_TARGET=META #     -  install: true script: true #    Gradle (           ) before_cache: - rm -f $HOME/.gradle/caches/modules-2/modules-2.lock - rm -fr $HOME/.gradle/caches/*/plugin-resolution/ cache: directories: - $HOME/.gradle/caches/ - $HOME/.gradle/wrapper/ #  ,   Kotlin/Native    - $HOME/.konan/ #     Bintray    ,           deploy: skip_cleanup: true provider: script script: ./gradlew bintrayUpload -DMP_TARGET=$MP_TARGET -Pbintray_user=$BINTRAY_USER -Pbintray_key=$BINTRAY_KEY on: tags: true

यदि किसी कारण से वर्चुअल मशीन में से एक पर असेंबली विफल हो गई, तो मेटाडेटा और अन्य लक्ष्य अभी भी बिंट्रे सर्वर पर अपलोड किए जाएंगे। यही कारण है कि हम उनके एपीआई के माध्यम से बिंट्रे पर पुस्तकालय के स्वचालित रिलीज के साथ एक ब्लॉक नहीं जोड़ते हैं।

संस्करण को जारी करते समय, आपको यह सुनिश्चित करने की आवश्यकता है कि सब कुछ क्रम में है, और साइट पर नए संस्करण के लिए प्रकाशित बटन पर क्लिक करें, क्योंकि सभी कलाकृतियों को पहले ही अपलोड किया जा चुका है।

निष्कर्ष

इसलिए हमने अपने कोटलिन मल्टीप्लेट प्रोजेक्ट में निरंतर एकीकरण और निरंतर वितरण स्थापित किया।

कोडांतरण, परीक्षण चलाने और कलाकृतियों को प्रकाशित करने के कार्यों को समानांतर करने के बाद, हम प्रभावी रूप से हमें मुफ्त में उपलब्ध कराए गए संसाधनों का उपयोग करते हैं।

और यदि आप लिनक्स का उपयोग करते हैं (जैसे कि आर्कटिव इवानोव अर्किवानोव , रेकटिव लाइब्रेरी के लेखक), तो आपको अब हर बार एक नया संस्करण जारी करने के लिए लाइब्रेरी को प्रकाशित करने के लिए macOS (me) का उपयोग करने वाले व्यक्ति से पूछने की आवश्यकता नहीं है।

मुझे उम्मीद है कि इस लेख के जारी होने के बाद, नियमित गतिविधियों को स्वचालित करने के लिए अधिक परियोजनाएं इस दृष्टिकोण का उपयोग करना शुरू कर देंगी।

आपका ध्यान के लिए धन्यवाद!