AfterPack API keys

एक API key local build को Pro Cloud build में बदल देती है। इसके बिना, npx afterpack@latest और हर plugin Free protection के साथ local रूप से चलते हैं और कुछ भी रिपोर्ट नहीं करते। इसके साथ, build की फ़ाइलें AfterPack के cloud engine पर जाती हैं, आपके workspace के हिसाब से meter होती हैं और dashboard में दर्ज होती हैं।

Keys कहाँ रहती हैं

Keys एक project के नीचे, उसके API कुंजियाँ पेज पर रहती हैं: एक key एक project से bound होती है, और उसकी builds वही project inherit करती हैं, जिससे builds, protection maps और usage उसी के नीचे समूहित होते हैं। बाकी हर अर्थ में key एक workspace-wide credential है: यह workspace के allowance से खर्च करती है और workspace role से नियंत्रित होती है।

Key बनाना

केवल workspace owners और admins ही key बना सकते हैं, और केवल dashboard से। एक key दूसरी key नहीं बना सकती। Create dialog ये माँगता है:

• नाम (ज़रूरी, 100 characters तक): यह किस लिए है, उदाहरण के लिए CI पाइपलाइन। बाद में rows को अलग पहचानने वाली यही एकमात्र चीज़ है, इसलिए इसका नाम उस चीज़ के नाम पर रखें जो इसे रखेगी।
• समाप्ति तिथि (वैकल्पिक, उन्नत विकल्प के नीचे): एक तारीख, जो local समय के अनुसार दिन के अंत पर तय होती है। बीती हुई तारीख error लौटाती है।
• अनुमत IP (वैकल्पिक, उन्नत विकल्प के नीचे): comma से अलग की गई सूची, उदाहरण के लिए 10.0.0.0/8, 203.0.113.7।

Keys ap_v1_ के बाद 40 random base62 characters जैसी दिखती हैं, और सूची केवल stored prefix (ap_v1_ और छह characters) एक * के साथ दिखाती है। Key builds को अपने project के नाम दर्ज करती है, लेकिन यह सीमित नहीं करती कि कोई build किस project को target कर सकती है। scope.allowedProjects एक error लौटाता है।

Key इस्तेमाल करना

Engine key को पहले --key= से, फिर environment से, फिर afterpack.json से resolve करता है। CI में AFTERPACK_key को secret के रूप में सेट करें, या local trial के लिए इसे afterpack.json में रखें:

{ "key": "ap_v1_..." }

दोनों में से किसी जगह key न होने का मतलब है कि build local रूप से चलती है: यही डिफ़ॉल्ट है, और पूरा Free tier वाला रास्ता।

Key सूची

Rotate करना

In-place rotate नहीं होता। Rotation हमेशा पहले नई बनाएँ, फिर पुरानी revoke करें होता है, और चूँकि key अपने आप कभी expire नहीं होती जब तक आपने बनाते समय समाप्ति सेट न की हो, दोनों rollout में जितना समय लगे, उतनी देर साथ-साथ चल सकती हैं:

1. नई key बनाएँ।
2. जहाँ-जहाँ पुरानी key इस्तेमाल होती थी (CI secrets, deploy configs), वहाँ इसे deploy करें।
3. अंतिम उपयोग column से पुष्टि करें कि builds इससे authenticate कर रही हैं।
4. पुरानी key revoke करें।

Revoke करना

Revoke करना तुरंत होता है और इसे पूर्ववत नहीं किया जा सकता: key अगली request पर काम करना बंद कर देती है। Row ग़ायब होने के बजाय निरस्त चिह्नित होकर दिखाई देती रहती है, ताकि आप देख सकें कि यह किस लिए इस्तेमाल होती थी। Key को उसका creator revoke कर सकता है, और उसके workspace का कोई भी admin या owner भी, इसलिए किसी ऐसे व्यक्ति की बनाई key भी revoke की जा सकती है जो तब से जा चुका है। Revoke करना एक dashboard action है: कोई API key किसी key को revoke नहीं कर सकती, अपने आप को भी नहीं। Build के बीच revoke की गई key के साथ CLI की अगली request विफल हो जाती है।

Key वाली build किन limits के तहत चलती है

जो build किसी limit को पार करती है, वह unobfuscated output पर लौटने के बजाय विफल होती है। Wire protocol और error codes के लिए Cloud API देखें।

जब builds दिखाई न दें

लगभग हमेशा इनमें से कोई एक कारण होता है:

1. कोई key resolve नहीं हुई: build local रूप से चली। जाँचें कि जहाँ build चलती है, वहाँ AFTERPACK_key सेट है।
2. Key revoke हो चुकी है या expire हो गई है: सूची बताती है कि कौन-सा।
3. आप गलत project देख रहे हैं: build key के project के नाम दर्ज होती है, जो आपके खुले project से अलग हो सकता है।

आगे

• Builds: key वाली build क्या बनाती है।
• Usage और billing: इसकी लागत क्या है।
• Cloud API: वह protocol जिसे key authenticate करती है।
• Workspaces और projects: वे roles जो इस पेज तक पहुँच नियंत्रित करते हैं।