AfterPack
Markdown में देखें

Dashboard में builds

हर Pro Cloud build का अपना record: coverage, inflation, complexity, build time, लागत, diagnostics और Protection Map।

हर Pro Cloud build एक record छोड़ती है: वह कब चली, किस commit से आई, उसकी लागत क्या रही, engine उसका कितना हिस्सा transform कर सका, और ऐसा करते हुए engine ने क्या रिपोर्ट किया। Free local builds कभी AfterPack से संपर्क नहीं करतीं, इसलिए वे यहाँ कभी नहीं दिखतीं।

Build list

एक project की हर build, सबसे नई पहले।

Columnयह क्या है
बिल्ड किया गयाBuild कब चली।
कमिटवह git SHA जो AfterPack ने build के लिए पहचाना (देखें seed), छोटा दिखाया जाता है और पूरा copy होता है, ताकि row को किसी deploy से जोड़ा जा सके।
फ़ाइलेंवे output फ़ाइलें जो इस build ने AfterPack को भेजीं, उनके भीतर की source फ़ाइलें छोड़कर।
आउटपुटProtection के बाद जो ship हुआ।
बिल किया गयावे input bytes जो AfterPack ने process किए। आपसे इसी का शुल्क लिया जाता है।
बिल्ड समयवह समय जो AfterPack ने build में जोड़ा, edge पर मापा गया; पुरानी builds में यह record नहीं है, इसलिए वे rows 0 के बजाय खाली दिखती हैं।
कवरेजप्राप्त output का वह हिस्सा जिसे transform करने के लिए engine स्वतंत्र था।
इन्फ्लेशनOutput ÷ input। Protection आपके users को download में इतनी महँगी पड़ती है।

List इस project की सबसे हाल की builds दिखाती है। किसी build को देखते समय sidebar उस project की पास की builds को बिल्ड के नीचे nest करता है, ताकि आप एक click में दो builds की तुलना कर सकें।

एक build, पूरी

किसी row को खोलें तो header में commit होता है (या git context न होने पर build id) और Protection Map देखें button, या जब खोलने को कुछ न हो तो एक मैप सहेजा नहीं गया chip।

परिणाम

चार संख्याएँ, और हर एक अलग सवाल का जवाब देती है।

  • कवरेज: प्राप्त output का वह हिस्सा जिसे transform करने के लिए engine स्वतंत्र था।
  • इन्फ्लेशन: output ÷ input size, वह संख्या जिसकी कीमत आपके users चुकाते हैं। कुछ बढ़ोतरी अपेक्षित है, क्योंकि code को पढ़ने में कठिन बनाने वाले transforms जगह लेते हैं।
  • जटिलता: eligible bytes पर पहुँची औसत complexity, इस build के target के सामने दिखाई गई (score / target)। Complexity सलाहकारी है और security को नहीं मापती।
  • आकार: क्या अंदर गया, और क्या ship हुआ।

कवरेज संरचना

Input का हर byte कहाँ गया। Bands का जोड़ input के बराबर है, और उनके हिस्से ऊपर के कवरेज से मेल खाते हैं।

Bandअर्थ
पात्रवे bytes जिन्हें transform करने के लिए engine स्वतंत्र था।
सुरक्षा-संरक्षितवे bytes जिन तक engine नहीं पहुँच सका, क्योंकि वह उन constructs को सुरक्षित रूप से represent नहीं कर सकता था।
रिफ़्लेक्शन-संरक्षितवे bytes जो इसलिए सुरक्षित रखे गए क्योंकि आपका code runtime reflection इस्तेमाल करता है।
आपने बाहर रखाआपकी paths.exclude setting से मेल खाने वाली फ़ाइलें, जो parsing से पहले छोड़ दी गईं और बिना बदलाव लौटाई गईं।
आपने छोड़ावे regions जिन्हें आपने /* @afterpack skip */ से चिह्नित किया।
बिना हिसाबवे input bytes जो किसी दूसरे band में नहीं हैं।

Bands के साथ: कमज़ोर जगहें (आपके source की वे strings जो output में अब भी पढ़ी जा सकती हैं, property names को छोड़कर; कहाँ हैं यह देखने के लिए map खोलें) और निर्देश (आपके source में engine को मिले @afterpack markers, जो यहाँ दर्ज होते हैं; इसी से आप पुष्टि करते हैं कि कोई marker पकड़ा गया)।

सोर्स फ़ाइलें

Build की हर source फ़ाइल का एक treemap, जिसका आकार अंदर गए bytes से तय होता है और रंग इस बात से कि engine कितनी दूर पहुँचा: grey tiles पर काम करने को कुछ नहीं था, red tiles का मतलब है कि कुछ गलत हुआ, और orange से green कमज़ोर से मज़बूत दिखाता है। Tiles केवल उस output को कवर करती हैं जो किसी फ़ाइल तक वापस trace हो सकता है, यानी आप जो ship करते हैं उसका लगभग आधा, इसलिए किसी tile का inflation build का inflation नहीं है। बाकी वह runtime है जो AfterPack हर bundle में एक बार inject करता है। Shared runtime code की कोई tile नहीं होती, इसीलिए एक build किसी भी अकेली फ़ाइल से ज़्यादा inflate होती है।

यह row paid plans तक सीमित है: Free workspace को treemap की जगह एक locked state दिखती है, हालाँकि build पेज की बाकी हर row मुफ़्त है।

आउटपुट फ़ाइल कैप्चर

यह बताता है कि build की कितनी output फ़ाइलें stored map में देखी जा सकती हैं, और बाकी के साथ क्या हुआ; यह protection को नहीं मापता, क्योंकि हर फ़ाइल obfuscate हुई, चाहे वह capture हुई हो या नहीं। एक अपवाद: अगर कोई build AfterPack के time budget तक पहुँच जाती है, तो वह नई फ़ाइलें शुरू करना बंद कर देती है, और बची हुई हर फ़ाइल fail होती है। Build दोबारा चलाएँ, या उसे छोटी builds में बाँटें।

समय

वह समय जो build ने AfterPack के edge पर बिताया, response के download होने का इंतज़ार भी शामिल। इसका बड़ा हिस्सा Protection Map है: उसे बनाना और लौटाना obfuscation के समय में जुड़ता है, इसलिए project settings में capture बंद करने से वह समय वापस मिल जाता है।

बिलिंग

इस build ने आपके workspace से क्या लिया: मापा गया (bill किए गए input bytes) और वह कहाँ से आया: भत्ता, क्रेडिट (Extra MB), अतिरिक्त।

निदान

इस build को obfuscate करते समय engine ने क्या रिपोर्ट किया, एक stable code के हिसाब से समूहित और गिनती के साथ; क्योंकि यह आपके अपने workspace में आपकी अपनी build है, आपको हर entry का message और फ़ाइल भी दिखती है। Informational entries अपेक्षित हैं, इसलिए केवल errors और criticals को highlight किया जाता है।

पेज बताता है कि तीन में से क्या हुआ: entries दर्ज हुईं, build साफ़ थी और उसने कुछ रिपोर्ट नहीं किया, या AfterPack के पास कोई record ही नहीं है, जो एक Free build के साथ होता है।

हर code stable है और bug report में quote किया जा सकता है। देखें Diagnostics।

Protection Map

जब capture चालू हो और build ने एक map store किया हो, तो Protection Map देखें per-token view खोलता है: आपका मूल source, हर token के complexity score के आधार पर रंगा हुआ, और साथ में आपके चुने हुए code की reversal class। Stored map में आपका मूल source होता है और workspace में हर कोई उसे पढ़ सकता है; retention और per-project switch Privacy और data handling पर हैं, और यह पेज build की सटीक retention तारीख बताता है। जिस build का कोई stored map नहीं है, वह उसकी जगह कारण बताती है: capture बंद था, वह Pro Cloud build नहीं थी, या उसमें map बनाने के लिए कोई input source maps नहीं थे।

Trends

Project overview समय के साथ coverage, inflation और build time को एक adaptive bucket size पर दिखाता है, पिछले हफ़्ते या महीने के मुकाबले delta के साथ; workspace overview हर project में usage के लिए यही करता है।

आगे