Workflows: Android पर डेव कार्य स्वचालित करें, बिना सर्वर के

हर डेवलपर के पास वही छोटे-छोटे दोहराए जाने वाले काम जमा हो जाते हैं: push के बाद टेस्ट चलाना, deploy होने पर डेटाबेस का बैकअप लेना, सहेजते समय फ़ॉर्मैट करना, बिल्ड टूटने पर बताना। लैपटॉप पर आप यह सब CI runners, cron कार्यों और किसी सर्वर पर पड़ी दो-चार shell स्क्रिप्ट से जोड़ते हैं। फ़ोन पर आम जवाब होता है «यह नहीं हो सकता»। Pocket Code Workflows से यह बदल देता है: एक इवेंट-चालित स्वचालन इंजन जो आपको Android पर कार्य स्वचालित करने देता है, पूरी तरह डिवाइस पर — न कोई सर्वर किराए पर, न क्लाउड में कुछ जीवित रखने को।

एक workflow बताना आसान है: एक ट्रिगर (IDE के भीतर की कोई घटना, या एक शेड्यूल) और साझा संदर्भ पर चलने वाले चरणों का क्रम। असली डेव प्रवाह बनाने के लिए इतना काफ़ी है — वैसे ही जिनके लिए आप आमतौर पर एक CI पाइपलाइन खड़ी करते — और वह भी आपके एडिटर, टर्मिनल और डेटाबेस प्रबंधक के ठीक बगल में।

बनाने के चार तरीके

आपको कभी खाली कैनवास से शुरू नहीं करना पड़ता:

टेम्पलेट सक्रिय करने पर वह नई id वाली संपादन-योग्य प्रति में क्लोन हो जाता है, इसलिए उसे बदलना मूल को कभी नहीं छूता।

ट्रिगर: workflow को कौन जगाता है

Workflows उन घटनाओं को सुनते हैं जो IDE से होकर बहती हैं। इंजन ऐप के आंतरिक bus को सब्सक्राइब करता है और हर घटना को एक ट्रिगर प्रकार से जोड़ता है। कुल पच्चीस प्रकार हैं, और एक workflow एक मुख्य ट्रिगर के साथ जितने चाहें उतने अतिरिक्त रख सकता है:

फ़िल्टर typed है, और पिछले संस्करणों की तुलना में यह असली बदलाव है: हर ट्रिगर अपने फ़ील्ड घोषित करता है, और आप ऑपरेटरों — बराबर, शामिल, से शुरू, मेल खाता, path glob — से फ़ील्ड की तुलना मान से करते हैं। अब यह घटना के टेक्स्ट में substring खोजना नहीं है। और चूँकि पहली बार में फ़िल्टर कोई सही नहीं लिखता, एडिटर में अगली घटना पकड़ो बटन है: आप वह काम करते हैं, और वह आपको ट्रिगर का असली payload दिखाता है ताकि आप फ़िल्टर किसी मौजूद चीज़ पर लिखें।

हर प्रकार को आज कोई उत्सर्जित नहीं करता। दो आज कभी नहीं चलते: प्रोजेक्ट बंद और AI एजेंट का turn समाप्त। push घटना में branch का नाम नहीं होता, इसलिए branch पर लगा फ़िल्टर कभी मेल नहीं खाता, और 17 में से दो टेम्पलेट (main पर push होते ही Auto-Deploy और main पर push के बाद टेस्ट) इसी तरह फ़िल्टर करते हैं। इसे छिपाने के बजाय, समस्या पैनल चेतावनी देता है कि यह workflow ऐसा ट्रिगर उपयोग कर रहा है जो आज कभी नहीं चलेगा।

शेड्यूलिंग: आपके फ़ोन पर cron, बिना सर्वर

यहीं «बिना सर्वर वाला स्वचालन» ठोस बनता है। किसी भी workflow में एक या अधिक शेड्यूल हो सकते हैं: एक पहले से तय अंतराल (हर 15 मिनट, हर घंटे, हर 6 घंटे), या पाँच-फ़ील्ड cron अभिव्यक्ति — wildcard *, सूची N,M, श्रेणी N-M और step */N के साथ। टाइप करते समय स्क्रीन अगला ट्रिगर समय दिखाती है या बताती है कि अभिव्यक्ति गलत है।

तीन बातें जानने लायक:

• DST सुलझा हुआ है। शेड्यूल डिवाइस के समय-क्षेत्र का उपयोग करते हैं (समय-क्षेत्र चुनने का विकल्प नहीं है)। वसंत में जो घंटा होता ही नहीं, वहाँ छलांग पर चलता है; पतझड़ में जो घंटा दो बार आता है, वहाँ एक ही बार चलता है। यह परखा गया है।
• छूटे हुए के लिए नीति। आप चुनें: डिवाइस बंद रहने के दौरान जो छूटा उसे छोड़ दें, या ऐप दोबारा शुरू होने पर एक बार चलाएँ। एक बार — लंबे सप्ताहांत की अड़तालीस बार नहीं।
• डिवाइस की शर्तें। कोई भी नेटवर्क, केवल Wi-Fi या कोई नहीं; केवल चार्ज होते समय; कम बैटरी पर नहीं; केवल डिवाइस निष्क्रिय होने पर। शर्त run को टालती है, रद्द नहीं करती, और स्क्रीन यही शब्दों में कहती है।

और एक असहज सच्चाई: Android पंद्रह मिनट से अधिक बार पृष्ठभूमि कार्य नहीं चलाता। इससे कम अंतराल बढ़ा दिया जाता है और ऐप सटीक संख्या बताता है। इससे कम cron को कोई नहीं बढ़ाता, इसलिए एकमात्र सच यह है कि कोई गारंटी नहीं — और स्क्रीन यही कहती है, बजाय एक गढ़ी हुई संख्या के।

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

शाखाएँ, लूप और सब-workflows

एडिटर कतार में लगे चरणों की सूची नहीं है। सात तरह के चरण हैं, जिनमें छह नियंत्रण-प्रवाह हैं, और शाखाएँ शाखाओं के भीतर नेस्ट होती हैं: आप जो बनाते हैं वह एक वृक्ष है।

• if / else — दो शाखाएँ। शर्त एक वृक्ष है, एक अकेला खाना नहीं: And, Or और Not नेस्ट होते हैं, इसलिए «टेस्ट पास हुए और शाखा main है» एक शर्त है, दो workflows नहीं।
• समानांतर — एक साथ N शाखाएँ, तीन तरह से जुड़तीं: सब पूरी हों, पहली जो खत्म हो, या पहली जो सही खत्म हो। अंतिम दो हारने वाली शाखाएँ रद्द कर देती हैं ताकि वे साइड इफ़ेक्ट करना बंद करें।
• हर एक के लिए — सूची पर पुनरावृत्ति, प्रति-आइटम उपनाम, पुनरावृत्तियों की सुरक्षा सीमा और एक साथ चलने वाली पुनरावृत्तियों की वैकल्पिक संख्या के साथ।
• try / विफल होने पर — पहले ब्लॉक में कुछ विफल हो तो दूसरा चलता है, और त्रुटि संदेश आपके नामित चर से बँधा होता है।
• सब-workflow — इसी run के भीतर दूसरा पूरा workflow चलाता है, अपने inputs के साथ। यही एक लंबे workflow को पुन: उपयोग-योग्य टुकड़ों में बदलता है।
• प्रतीक्षा — कुछ समय, या जब तक कोई घटना न हो, समय अधिकतम सीमा के रूप में। «deploy खत्म होने तक रुको», न कि «दो मिनट रुको और उम्मीद करो»।

और नियंत्रण-चरण बनाए बिना भी: हर क्रिया-चरण की अपनी वैकल्पिक शर्त हो सकती है। झूठी हो तो चरण छोड़ दिया जाता है, बिना उसे पूरे if / else में लपेटे।

पंद्रह क्रियाएँ, सभी जुड़ी हुई

क्रिया-चरण पंद्रह हैं, और पंद्रहों सचमुच चलने वाली किसी चीज़ से जुड़ी हैं: कमांड चलाना, HTTP अनुरोध, git ऑपरेशन, deploy, डेटाबेस क्वेरी या बैकअप, फ़ाइल पढ़ना/लिखना/जाँचना, उसे एडिटर में खोलना, AI से विश्लेषण या निर्माण, मान बदलना, चर सेट करना, और सूचना देना।

पंद्रहों का कार्यान्वयन होना प्रस्तुति का विवरण नहीं है: एक टेस्ट लाल होकर उस प्रकार का नाम बताता है जो अपना कार्यान्वयन खो दे। जिस प्रकार के पीछे कुछ नहीं, वह चुपचाप सफलता देने के बजाय ज़ोर से विफल होता है।

कुछ सीमाएँ जानना ज़रूरी है। Deploy चरण केवल Render, Netlify और DigitalOcean को चलाता है (branch या environment दर्ज होते हैं पर माने नहीं जाते)। git चरण में सात ऑपरेशन हैं: status, commit, push, pull, checkout, log और diff। डेटाबेस क्वेरी आपके Neon, Supabase, Turso या Upstash कनेक्शन में से किसी एक का नाम लेती है। और चर सेट करना अपना मान {{step.<id>.output.value}} के रूप में लौटाता है; यह {{var.name}} नहीं बनाता।

कोई चरण विनाशकारी है या नहीं, यह उसके पैरामीटर सामने रखकर तय होता है, प्रकार से नहीं: git status, git push नहीं है, और SELECT, DROP नहीं है। पूरे प्रकार को विनाशकारी कहने पर status तक की पुष्टि करनी पड़ेगी, और हर चीज़ पर पुष्टि माँगना लोगों को बिना पढ़े स्वीकार करना सिखाता है।

चरणों के बीच डेटा भेजना

चरण एक संदर्भ साझा करते हैं, और कोई भी फ़ील्ड दोहरे ब्रेस वाली अभिव्यक्ति से दूसरे को संदर्भित कर सकता है:

साथ में तेरह श्रृंखलाबद्ध फ़िल्टर: lines, first, last, trim, upper, lower, length, json, default, split, join, date, replace। तो किसी कमांड के आउटपुट की पहली पंक्ति यह है: {{step.sh.output.stdout | lines | first | trim}}।

फ़िल्टर के तर्क हमेशा उद्धरण चिह्नों में लिखे जाते हैं, जैसे replace:"a":"b"। जो अभिव्यक्ति हल न हो वह जान-बूझकर खाली स्ट्रिंग देती है, ताकि उस शाखा के चरण का संदर्भ जो कभी चली ही नहीं, पूरा run न गिरा दे।

विश्वसनीयता: पुनःप्रयास, टाइमआउट, और विफल होने पर क्या

हर क्रिया-चरण पुनःप्रयास नीति (स्थिर, रैखिक या घातांकी प्रतीक्षा और उस प्रतीक्षा की सीमा के साथ) और एक टाइमआउट लेता है, और हर चरण में विफल होने पर क्या करें की नीति होती है: run रोकें या जारी रखें।

दो बातें जो ठोकर खाकर ही पता चलती हैं:

• विफलता के बाद जारी रखने से पूरा run नहीं रंगता। चरण अपनी त्रुटि के साथ लाल रहता है, पर run हरा निकलता है — वही भेद जो GitHub Actions में continue-on-error करता है।
• टाइमआउट भी विफलता गिना जाता है। चरण «समय समाप्त» चिह्नित होकर लौटता है और यदि उसके पास प्रयास बचे हों तो उसे फिर आज़माया जाता है।

और किसी चरण को मिटाए बिना बंद किया जा सकता है, जो डिबग करते समय आप चाहते हैं, न कि उसे मिटाकर दोबारा लिखना।

इसके अलावा, हर बार पैरामीटर बदलने पर पूरा workflow चलाने के बजाय — उसके deploy और सूचनाओं समेत — आप पिन किए डेटा को संदर्भ मानकर अकेला चरण परख सकते हैं। जो चरण सिमुलेट नहीं हो सकता उसे सिमुलेट नहीं किया जाता: बटन «इस चरण को सचमुच चलाएँ» कहता है और पहले पूछता है। बिना कुछ चलाए «ठीक है» कहने वाला बटन, बटन न होने से बुरा है।

अनुमतियाँ और secrets

एक workflow घोषित करता है कि उसे क्या करने की अनुमति है: नेटवर्क पर जाना, फ़ाइलें लिखना, कमांड चलाना, और जिन डोमेन तक पहुँच सकता है उनकी सूची। कार्यान्वयन कुछ भी छूने से पहले जाँचते हैं, और अस्वीकृति बताती है कि कौन-सी अनुमति थी, क्या चलने वाला था और उसे कहाँ बदलें। सब-workflow अनुमतियों का प्रतिच्छेदन पाता है: जो माता-पिता ने बंद किया वह खोल नहीं सकता।

यह sandbox नहीं है, और स्क्रीन यह कहती है: जो workflow संपादित कर सकता है वह यह बेल्ट खोल सकता है। यह लापरवाही से बचाता है — वह workflow जो आपने AI को खोला, जो किसी ने भेजा, या वह curl जिसे किसी ने «बस परखने को» चिपकाया और छोड़ दिया।

Secrets प्रति खाता एक एन्क्रिप्टेड स्टोर में रहते हैं। आप उन्हें {{secret.NAME}} से संदर्भित करते हैं और मान फिर कभी नहीं दिखाया जाता, उसकी अपनी स्क्रीन पर भी नहीं। वे केवल असली run में हल होते हैं; मास्किंग हर संग्रहीत मान को ढकती है, केवल पढ़े गए को नहीं; और यह डेटाबेस में लिखने से पहले होता है, स्क्रीन बनाते समय नहीं — पेंट के समय ढकना देर हो जाएगी, मान पहले ही फ़ाइल और किसी भी बैकअप में होगा।

ऐसा run इतिहास जिसे आप सचमुच जाँच सकें

हर पूरा हुआ run पूरा लिखा जाता है: हर चरण का परिणाम, कितना समय लगा, कितने प्रयास चाहिए थे, और त्रुटि हुई तो वह भी। पूरे हुए runs ऐप बंद होने से बच जाते हैं; जो run Android द्वारा प्रक्रिया मारे जाने के समय चल ही रहा हो उसकी कोई पंक्ति नहीं बचती, और shell चरण का लॉग सहेजा नहीं जाता। गतिविधि टैब सभी workflows का दृश्य है, स्थिति, तिथि, workflow और त्रुटि-पाठ से फ़िल्टर करने योग्य।

प्रतिधारण आप तय करते हैं: डिफ़ॉल्ट 100 runs और 30 दिन, 1 से 1,000 runs और 1 से 365 दिन तक।

एक को साझा करना

एक workflow .pcwf.json फ़ाइल के रूप में यात्रा करता है। जो साथ नहीं जाता: इतिहास, पिन किए आउटपुट, शेड्यूल और चालू/बंद स्विच। जो पहुँचता है वह निष्क्रिय और नई id के साथ आता है।

गुप्त चिह्नित पैरामीटर मान फ़ाइल लिखने से पहले खाली कर दिए जाते हैं और सूचीबद्ध किए जाते हैं, ताकि खोलने वाला जाने कि उसे क्या भरना है। {{secret.X}} संदर्भ साथ जाता है: वह एक नाम है, secret नहीं, और उसे खाली करना workflow को अपूरणीय रूप से तोड़ देगा। बाक़ी सब कुछ ठीक वैसे ही जाता है जैसा आपने लिखा, HTTP headers और कमांड समेत, इसलिए साझा करने से पहले फ़ाइल जाँच लें।

इसे सादी भाषा में बताएँ

यदि आप चरण हाथ से जोड़ना नहीं चाहते, तो एक वाक्य लिखें। मॉडल का उत्तर जहाँ संभव हो वहाँ ठीक किया जाता है, linter से गुज़रता है, dry-run होता है, और कुछ भी सहेजने से पहले परिणाम आपको दिखाया जाता है। आप उससे मौजूदा को बदलने को भी कह सकते हैं: उत्तर ऊपर मिला दिया जाता है, id, स्विच और तिथि रखते हुए, और आपको diff मिलता है।

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

और उल्टा भी: जिस workflow पर आप «AI एजेंट के लिए उपलब्ध» लगाते हैं, वह चैट में औज़ार के रूप में सामने आता है और एजेंट उसे बुला सकता है। ऊपर का generator मुफ़्त है; AI चैट से workflows बनवाना या अपडेट करवाना Pro सुविधा है।

आपका स्वचालन आपके डिवाइस पर ही रहता है

परिभाषाएँ, इतिहास और शेड्यूल आपके फ़ोन के स्थानीय डेटाबेस में रहते हैं। परिभाषाओं का क्लाउड बैकअप पुनर्स्थापना के लिए हो सकता है (Cloud Sync, Pro सुविधा), पर आपका स्वचालन चलाने के लिए क्लाउड से कभी कुछ नहीं पढ़ा जाता: इंजन स्थानीय रूप से चलता है, बस। इतिहास और शेड्यूल बिल्कुल सिंक नहीं होते: इतिहास डिवाइस-स्थानीय है, और शेड्यूल हर डिवाइस की अपनी WorkManager स्थिति हैं।

अंत में एक ईमानदार बात: यहाँ शाखाएँ एक नेस्टेड वृक्ष हैं, कैनवास पर जोड़े गए नोड नहीं। न N-मार्गी switch है, न किसी शाखा को नीचे के किसी विशिष्ट नोड से जोड़ने का तरीका। webhook ट्रिगर भी नहीं है, और workflows को Marketplace से इंस्टॉल या उसमें प्रकाशित नहीं किया जा सकता (इंस्टॉल बटन निष्क्रिय है)। अपना workflow साझा करना यानी फ़ाइल साझा करना।

PocketCode Google Play की ओर बढ़ रहा है, और एक पूरा स्वचालन इंजन — पच्चीस ट्रिगर, शाखाएँ, फ़ोन पर cron, अनुमतियाँ और secrets — उसी ऐप में ला रहा है जहाँ आप कोड लिखते और प्रकाशित करते हैं। प्री-रजिस्ट्रेशन में शामिल हों और अपने ही डिवाइस पर इसे आज़माने वालों में सबसे पहले बनें।