چرخهٔ انتشار#

انتشار در الامر یک ماشین وضعیت وابسته به چکیده است، نه یک پرچم قابل ویرایش روی پروژه. revision محیط، revision اپ، نسخهٔ پلاگین و revision استقرار بک‌اند مقصدهای مستقلی هستند. هر درخواست انتشار یک مقصد و شواهد بستهٔ آن را ثابت می‌کند، بررسی‌ها را اجرا می‌کند، وارد ارزیابی انسانی می‌شود و فقط پس از آن می‌تواند اختیار کاتالوگ یا زمان اجرا بگیرد.

چهار مقصد انتشار#

مقصد	محتوای ثابت	چکیدهٔ بسته
environment_revision	ورودی/نسخهٔ bundle، سیاست ورود، نمایش در پرتال، قابلیت‌ها، نصب دقیق پلاگین‌ها و بایت‌های frontend بارگذاری‌شده	integrity از نوع SHA-512 برای bundle قطعی Environment
app_revision	ورودی bundle، حالت‌های نمایش، قابلیت‌ها، اعلان‌ها، disclosureها، سازگاری Contracts/SDK و بایت‌های frontend بارگذاری‌شده	چکیدهٔ یک فهرست تغییرناپذیر bundle که پیش از submit متصل شده است
plugin_release	مانیفست پلاگین، نسخهٔ معنایی، آداپترها، قرارداد مولفه‌های بک‌اند، تنظیمات، مجوزها، توضیحات اعتماد، سازگاری و مستندات	چکیدهٔ مجموعهٔ مرتب و دقیق artifactهای ثابت‌شده هنگام درخواست
backend_deployment_revision	نشانی یک مولفهٔ بک‌اند، نشانی اختیاری سلامت و پیکربندی عمومی و غیرمحرمانه	null؛ شواهد استقرار با چکیدهٔ مستقل همان بازبینی مشخص می‌شود

بنابراین پلاگین تمام‌پشته دست‌کم دو موضوع انتشار مستقل دارد: نسخهٔ پلاگین و یک بازبینی استقرار برای هر مولفهٔ بک‌اند اعلام‌شده. نشانی زنده هیچ‌گاه داخل نسخهٔ پلاگین قرار نمی‌گیرد.

ماشین وضعیت#

نمودار اجرایی گذارها:

draft
  ├─> checks_running ─> ready_for_review ─> in_review ─> approved ─> published
  │          │                                  └─> rejected
  │          └─> checks_failed ─> checks_running
  └─> withdrawn

checks_running, checks_failed, ready_for_review, and in_review may also
transition to withdrawn.

published ─> yanked
          └> suspended

وضعیت‌های rejected، withdrawn، yanked و suspended در قرارداد عمومی گذار خروجی ندارند. published فقط می‌تواند به yanked یا suspended برود. در API عمومی گذار، رفتن به rejected، withdrawn، yanked یا suspended نیازمند reason است.

معنی هر وضعیت#

وضعیت	معنی	عامل یا عملیات معمول
draft	درخواست ساخته شده و به چکیده‌های مقصد متصل است، اما بررسی کامل نشده	مالک پروژه، CLI، کنسول یا API مدیریت
checks_running	رجیستری مقصد و شواهد ثابت را بررسی می‌کند	alamr test یا API بررسی
checks_failed	دست‌کم یک بررسی الزامی شکست خورده است	مالک علت را رفع و alamr test را دوباره اجرا می‌کند
ready_for_review	همهٔ بررسی‌ها موفق بوده‌اند یا هشدار داشته‌اند و درخواست می‌تواند وارد بازبینی شود	alamr publish یا API ارسال
in_review	درخواست در صف ارزیابی قرار دارد	بازبین مجاز
approved	بازبین همان چکیدهٔ نسخهٔ ثابت و بسته را تأیید کرده؛ انتشار هنوز گذار مدیریتی می‌خواهد	بازبین مجاز
published	مقصد منتشر شده و می‌تواند مقصد فعال کاتالوگ یا زمان اجرای پروژه شود	مدیر رجیستری
rejected	بازبینی درخواست را رد کرده است	تصمیم بازبین
withdrawn	درخواست پیش از انتشار پایان یافته است	مالک یا مدیر از راه گذار مجاز
yanked	مقصد منتشرشده با گذار نهایی مدیریتی پس گرفته شده است	مدیر رجیستری
suspended	مقصد منتشرشده با گذار نهایی مدیریتی تعلیق شده است	مدیر رجیستری

هشدار باعث شکست مجموعه بررسی‌ها نمی‌شود: اگر همهٔ نتیجه‌ها passed یا warning باشند، رجیستری به ready_for_review می‌رود. وجود هر نتیجهٔ failed را checks_failed می‌کند.

از فایل محلی تا درخواست ثابت#

۱. یک پروژهٔ قابل ویرایش را پیوند دهید#

alamr link پروژهٔ environment، app یا plugin را می‌سازد یا پیوند می‌دهد و مبدأ رجیستری و projectId را در .al-amr/project.json ثبت می‌کند. شناسهٔ پایدار محیط یا پلاگین با شناسهٔ پروژه فرق دارد.

اگر نام Environment یا App نویسهٔ ASCII مناسب slug نداشته باشد، پیونددهی از نام و هویت محلی محصول handle پایدار می‌سازد. بنابراین پروژه‌های متمایز با نام کاملاً فارسی یک handle جایگزین ثابت مشترک ندارند. پیوند Plugin، slug صریح مانیفست را حفظ می‌کند.

Desktop ثبت‌های adoption، برنامه‌ها، قفل‌ها و رسیدهای بازیابی را زیر profile خود Electron نگه می‌دارد. CLI درون‌پردازه‌ای از همان profile استفاده می‌کند، نه پوشهٔ state به‌ارث‌رسیدهٔ CLI یا Windows LocalAppData. برنامه‌ریزی در فایل‌های پروژهٔ انتخاب‌شده نمی‌نویسد؛ state موجود بیرون profile حفظ می‌شود.

اگر schema قرارداد نصب‌شده مانیفست پروژه را رد کند، اعتبارسنجی و آماده‌سازی upload کد ALAMR_INSTALLED_CONTRACT_MISMATCH را حفظ می‌کنند. Desktop ناسازگاری را فارسی توضیح می‌دهد و نویسنده را به عمل تعمیر وابستگی‌های پروژه هدایت می‌کند. پیام تشخیصی اصلی CLI در envelope فرمان در دسترس می‌ماند. تعمیر همچنان به release ارتقایافتهٔ تأییدشده نیاز دارد؛ این پیام مجوز upload artifact ناسازگار نیست.

۲. مقصد تغییرناپذیر را بسازید#

alamr test ابتدا اعتبارسنجی محلی را اجرا می‌کند.

• برای Environment، alamr build و سپس alamr test --bundle dist، revision را می‌سازد یا دوباره استفاده می‌کند، bundle فرانت‌اند را قطعی بسته‌بندی و upload و مانیفست دقیق و integrity از نوع SHA-512 آن را bind می‌کند. اگر خروجی dist نیست از --bundle <dir> استفاده کنید.
• برای App، alamr build پوشهٔ dist را می‌سازد و alamr test بعدی در یک عملیات bundle را inventory، pack و upload، revision تغییرناپذیر نسل build را ایجاد و سند ورودی و همهٔ بایت‌های اعلام‌شده را bind می‌کند.
• برای پلاگین، نسخهٔ معنایی دقیق را می‌سازد یا دوباره به کار می‌گیرد. نسخهٔ موجود فقط وقتی قابل بازاستفاده است که مانیفست و محتوای بسته همچنان تطبیق کنند.
• برای هر مولفهٔ بک‌اند پیکربندی‌شده، بازبینی استقرار دقیقاً منطبق را می‌سازد یا دوباره به کار می‌گیرد.

تغییر مانیفست یا محتوای بسته زیر نسخهٔ موجود پلاگین تعارض است؛ نسخهٔ معنایی پلاگین را افزایش دهید. تغییر محتوای محیط یا استقرار، بازبینی دیگری می‌سازد. هر نسل build تغییریافتهٔ Environment همچنین به افزایش entry.version نیاز دارد. هر نسل build تغییریافتهٔ App یک revision تغییرناپذیر تازه می‌گیرد.

۳. شواهد بسته را ثابت کنید#

هنگام ساخت درخواست پلاگین، رجیستری مجموعهٔ مرتب و دقیق بسته‌های ثبت‌شده را به‌صورت نسخهٔ ثابت ثبت می‌کند و artifactDigest را می‌سازد. بایت‌های مدیریت‌شده باید از مرز artifact-validator عبور کنند. بسته‌های npm را رجیستری پیدا و آینه می‌کند. فقط بستهٔ اعتبارسنجی‌شده می‌تواند بررسی انتشار را بگذراند.

پیش از نخستین submission اپ، رجیستری دقیقاً یک AppBuildArtifact را به revision متصل می‌کند. فهرست normalizeشده سند ورودی، اندازهٔ کل و مسیر نسبی، اندازه و صحت SHA-512 هر فایل را ثبت می‌کند؛ buildDigest با SHA-256 روی محتوای canonical به artifactDigest درخواست تبدیل می‌شود. بایت‌های متفاوت نمی‌توانند این اتصال یا revision را دوباره استفاده کنند.

پیش از submission یک Environment، Registry آرشیو قطعی را نگه می‌دارد و integrity از نوع SHA-512 آن را به revision و submission متصل می‌کند. سند ورودی، cover اعلام‌شده و همهٔ assetهای اجرایی یا runtime از همین بایت‌ها می‌آیند؛ Registry frontend میزبانی‌شده نزد ناشر را fetch نمی‌کند.

درخواست بازبینی، چکیدهٔ موردانتظار نسخهٔ ثابت و بسته‌ها را می‌فرستد. رجیستری هنگام بازبینی و درست پیش از انتشار نهایی دوباره آن‌ها را مقایسه می‌کند. تغییر مجموعهٔ بسته‌ها به‌جای بازبینی بایت‌های دیگر، تعارض برمی‌گرداند.

۴. بررسی‌ها را اجرا کنید#

# Environment
alamr build --json
alamr test --bundle dist --json --visibility unlisted --channel preview

# App
alamr build --json
alamr test --yes --json

# Plugin
alamr test --json --visibility unlisted --channel preview

frontendهای Environment و App checks تک‌مرحله‌ای bundle دارند. آن‌ها از preview میزبانی‌شده نزد ناشر، handshake مسیر well-known یا handoff جداگانهٔ prepare/resume استفاده نمی‌کنند. submission یکسان و ازپیش‌آماده موفق برمی‌گردد و checks_failed checks را روی همان submission منطبق دوباره اجرا می‌کند. محتوای تغییریافته به revision تازهٔ Environment با entry.version بالاتر، نسل build تازهٔ App یا SemVer تازهٔ Plugin نیاز دارد؛ هرگز با ویرایش digest موجود تطبیق داده نمی‌شود.

مسیر بررسی فقط draft یا checks_failed را می‌پذیرد. درخواست را به‌صورت اتمیک به checks_running می‌برد و فهرست نتیجه را با وضعیت ready_for_review یا checks_failed ذخیره می‌کند.

CLI پیش از ادامه شناسهٔ مقصد و درخواست را محلی ثبت می‌کند تا فرمان قطع‌شده بتواند وضعیت سرور را ببیند و دوباره استفاده کند. بررسی شکست‌خورده روی همان درخواست تکرار می‌شود و alamr test فقط برای تلاش مجدد یک نسخهٔ تکراری نمی‌سازد.

بررسی‌های فعلی چه چیزی را اثبات می‌کنند؟#

مقصد	شواهد پیاده‌سازی‌شده
بازبینی Environment	schema/digest مانیفست و entry/version مربوط به bundle؛ SHA-512 آرشیو قطعی؛ وجود سند ورودی و cover اعلام‌شده؛ SemVer دقیق SDK؛ منتشر، unblock، adapter-valid، artifact-valid و سازگار بودن همهٔ Pluginهای نصب‌شده
revision App	schema/digest مانیفست و یک اتصال تغییرناپذیر bundle؛ انطباق سند ورودی و هر فایل فهرست‌شده با اندازه/SHA-512؛ SDK دقیق و سازگار؛ range سازگار Contracts؛ محدودیت تعداد فایل، اندازهٔ کل، مسیر و آرشیو
release Plugin	schema و digest مانیفست؛ مجموعهٔ دقیق artifactها؛ بستهٔ مدیریت‌شدهٔ معتبر؛ اشارهٔ هر مولفهٔ بک‌اند جدید به بایت OpenAPI/AsyncAPI داخل بسته با SHA-256 منطبق؛ permissions_disclosure ساختار اعلان را parse می‌کند، نه کیفیت معنایی متن آن را
revision استقرار بک‌اند	وجود مقصد و دسترس‌پذیری نشانی سلامت. این check دسترسی شبکه‌ای را ثابت می‌کند، نه درستی پروتکل بک‌اند در سطح کاربرد

۵. برای بازبینی بفرستید#

alamr publish --json --yes
alamr status --json

publish به مقصد بررسی‌شده و پیوندشده نیاز دارد. عملیات ارسال فقط ready_for_review را می‌پذیرد و آن را به in_review می‌برد؛ مقصد را تأیید یا منتشر نمی‌کند.

برای پلاگین full_stack یا backend_only، CLI نسخهٔ پلاگین و همهٔ درخواست‌های استقرار محلی را پیش‌بررسی می‌کند. هر مقصد باید در یکی از وضعیت‌های ready_for_review، in_review، approved یا published باشد و هر مقصد آماده همراه مجموعه ارسال می‌شود. اگر پیکربندی استقرار پس از بررسی عوض شده باشد، انتشار متوقف می‌شود و alamr test تازه لازم است.

فراخوانی‌های متعدد ارسال قابل ادامه‌اند، اما یک تراکنش اتمیک مشترک نیستند. اگر خطای شبکه یا سرور وسط کار رخ داد، alamr status --json و سپس alamr publish را دوباره اجرا کنید. مسیر تمام‌پشته مقصدهای in_review، approved و published را دست‌نخورده می‌گذارد و فقط ready_for_reviewهای باقی‌مانده را می‌فرستد.

۶. بازبینی و انتشار#

بازبین مجاز ابتدا work item را با نسخهٔ optimistic آن claim می‌کند، شواهد ثابت را می‌خواند و به‌عنوان بازبین تخصیص‌یافته approve یا reject می‌فرستد. تصمیم به نسخهٔ تخصیص، چکیدهٔ snapshot و چکیدهٔ artifact متصل است. رجیستری همهٔ تصمیم‌ها را دائمی نگه می‌دارد. رد کردن همچنین دسته، خلاصه و یک یا چند اقدام اصلاحی قابل اجرا را ذخیره می‌کند؛ پرونده‌های بسته به‌صورت تاریخچه خواندنی‌اند.

تأیید، in_review را به approved می‌برد و به‌طور اتمیک یک handoff انتشار متصل به چکیده‌های دقیق می‌سازد. مدیر دوم پلتفرم handoff را claim و منتشر می‌کند؛ تأییدکننده نمی‌تواند ناشر باشد. رجیستری نسخهٔ handoff، هویت تأییدکننده، هر دو چکیدهٔ ثابت، آمادگی مقصد و snapshot بسته را دوباره بررسی و انتشار و تکمیل handoff را در یک تراکنش commit می‌کند. مالک Project یا ارسال‌کنندهٔ درخواست، حتی با اختیار administrator یا reviewer، نمی‌تواند نسخهٔ خودش را تأیید کند. توکن Project و بررسی خودکار موفق نیز حق تأیید یا انتشار ندارند.

یافته‌های ساختاریافتهٔ diff و AI وضعیت تولیدکنندهٔ صریح دارند. baseline ناموجود baseline_unavailable و تولیدکنندهٔ AI پیکربندی‌نشده not_configured است. هیچ‌کدام به شاهد ساختگی یا تأیید خودکار تبدیل نمی‌شوند.

اگر submission تأییدشدهٔ Environment بعداً رد شود، هر handoff انتشار آماده یا claim‌شدهٔ آن درخواست به cancelled می‌رود، assignee آن پاک می‌شود و نسخهٔ optimistic افزایش می‌یابد. این رفتار عمداً مانع باقی‌ماندن مالکیت قدیمی ناشر پس از برگشت نهایی تصمیم بازبینی می‌شود.

اختیار reviewer یک اختیار مستقل پلتفرم است؛ نه رول Project است و نه دسترسی administrator. مدیر Registry آن را با دلیل ممیزی‌شده از مسیر /console/admin/reviewers در Developer Portal یا با فرمان alamr admin reviewers grant|revoke <userId> --reason <text> --yes اعطا یا لغو می‌کند. بازبین تفویض‌شده فقط می‌تواند صف بازبینی و شواهد تغییرناپذیر را بخواند، lease واجدشرایط بازبینی را تمدید کند و تصمیم approve یا reject بگیرد. این اختیار هیچ دسترسی به Project، مدیریت کاربران، جای‌گذاری Hub یا انتشار نهایی نمی‌دهد. لغو در هر درخواست Registry دوباره بررسی می‌شود و فوری اثر می‌کند. مدیران پلتفرم همچنان ذاتاً اختیار بازبینی دارند، اما همان جداسازی وظایف مالک و ارسال‌کننده دربارهٔ آن‌ها نیز اعمال می‌شود.

پس از انتشار:

• revision Environment به bundle فعال نگه‌داری‌شده تبدیل می‌شود که زیر سیاست ورود بازبینی‌شده به clientهای سازگار دسکتاپ ارائه می‌شود؛
• revision اپ، revision منتشرشدهٔ فعال می‌شود، اما تا عملیات جداگانهٔ enable توسط مدیر برای Runtime در دسترس نیست؛
• نسخهٔ پلاگین، نسخهٔ فعال آن می‌شود؛
• بازبینی استقرار بک‌اند منتشر می‌شود و وضعیت عملیاتی سالم و بررسی‌شده می‌گیرد.

Environment، App یا Plugin تازه‌منتشرشده در نخستین خواندن بعدی کاتالوگ Developer Portal مبتنی بر Registry دیده می‌شود. انتشار هرگز سورس Hub را ویرایش نمی‌کند، portal در Hub نمی‌سازد و placement آن را تغییر نمی‌دهد. placement در Hub تصمیم محصولی جداگانه‌ای است که باید صریح تألیف و بازبینی شود؛ راهنمای جای‌گذاری را ببینید.

انتشار نسخهٔ پلاگین و بازبینی‌های استقرار، گذارهای مدیریتی جدا هستند و یک تراکنش اتمیک واحد نیستند. مجوز بک‌اند پلاگین فقط وقتی صادر می‌شود که نسخهٔ دقیق نصب و بازبینی استقرار آن منتشر شده باشد.

برای App، گذار انتشار نهایی، enable سراسری و rollback همگی اتصال bundle نگه‌داری‌شده را پیش از تغییر state دوباره بررسی می‌کنند. revisionهای تاریخی App بدون مدرک bundle خواندنی هستند، اما تازه submit، published یا enabled نمی‌شوند و مقصد rollback نیستند.

CLI، API و کنسول از یک صفحهٔ کنترل استفاده می‌کنند#

CLI و کنسول ماشین وضعیت جداگانه‌ای برای انتشار ندارند:

گردش‌کار	CLI	API مدیریت
ساخت مقصد، درخواست و بررسی	alamr test	POST /v1/projects/{projectId}/environment-revisions یا plugin-releases، سپس POST /v1/publication-submissions و POST /v1/publication-submissions/{submissionId}/checks
ورود به بازبینی	alamr publish	POST /v1/publication-submissions/{submissionId}/submit
خواندن وضعیت	alamr status	GET /v1/projects/{projectId} و GET /v1/projects/{projectId}/publication-submissions
مالکیت و تصمیم بازبین	alamr review assignment، claim، release، history، evidence و decide	مسیرهای اختصاصی claim، evidence، history و تصمیم v2 با نسخهٔ خوش‌بینانهٔ تخصیص و چکیده‌های دقیق
انتشار handoff تأییدشده	alamr review handoff-list، handoff-inspect، handoff-claim و handoff-publish	مسیرهای اختصاصی claim و publish برای handoff؛ ناشر باید مدیر دوم باشد
پس‌گرفتن درخواست واجد شرایط	alamr publication transition	گذار مجاز به withdrawn همراه دلیل؛ کنسول از API مدیریت استفاده می‌کند
وضعیت مدیریتی غیرانتشار	alamr publication transition	/transition گذارهای مجاز غیرانتشار را انجام می‌دهد؛ approved به published فقط با handoff اختصاصی مدیر دوم ممکن است
بازگردانی مقصد فعال	alamr rollback	POST /v1/projects/{projectId}/rollback؛ کنسول همین API را صدا می‌زند

کنسول با نشست مبهم مرورگر و حفاظت CSRF وارد می‌شود. CLI و CI اعتبارنامه‌های جداگانه با دامنهٔ دسترسی مشخص دارند. صف و مسیر اختصاصی بازبینی مدیر پلتفرم یا بازبین تفویض‌شدهٔ فعال را می‌پذیرد و توکن پروژه را رد می‌کند. گذارهای مدیریتی انتشار، پس‌گرفتن و تعلیق نیز توکن پروژه را رد می‌کنند. کلاینت عمومی باید از مسیرهای اختصاصی بررسی، ارسال و بازبینی استفاده کند؛ مسیر عمومی گذار جایگزین این گردش‌کارها نیست.

بازیابی بر اساس وضعیت فعلی#

وضعیت یا نشانه	بازیابی امن
draft	محصول را دوباره build و check تک‌مرحله‌ای آن را اجرا کنید: برای Environment فرمان alamr test --bundle dist، برای App فرمان alamr test و برای Plugin فرمان alamr test. اگر مقصد اشتباه است، به‌جای ویرایش شواهد ثابت revision یا version تازه بسازید
checks_running	alamr status --json را بخوانید و منتظر عملیات فعلی بمانید. شروع بررسی تکراری تعارض می‌دهد
checks_failed	همهٔ checkهای ساختاریافته را بخوانید و مشکل bundle محلی یا deployment را رفع کنید. اگر بایت‌ها تغییر کردند دوباره build بگیرید، سپس همان فرمان محصول‌ویژهٔ alamr test را تکرار کنید؛ CLI فقط مقصد دقیقاً منطبق را بازاستفاده و checkها را درجا تکرار می‌کند
ready_for_review	alamr publish را یک‌بار اجرا کنید. برای دانستن وضعیت مرجع از status استفاده کنید
in_review	منتظر بازبین مستقل بمانید. مالک Project یا ارسال‌کننده حتی اگر administrator/reviewer باشد نمی‌تواند آن را تأیید کند؛ توکن Project نیز نمی‌تواند بازبینی کند
rejected	تصمیم و تاریخچهٔ بازبینی نهایی و تغییرناپذیرند. Registry فقط وقتی می‌تواند گردش‌کار همان درخواست را دوباره در draft باز کند که مقصد و snapshot منجمد artifact دقیقاً همان باشند؛ بررسی‌ها و بازبینی را دوباره اجرا کنید. اگر کد، مانیفست، پیکربندی Environment، استقرار یا بایت‌های artifact تغییر کرده‌اند، مقصد تازه بسازید؛ Plugin به SemVer تازه نیاز دارد
withdrawn	مقصد و درخواست تازه بسازید؛ شواهد پس‌گرفته‌شده را ویرایش نکنید
approved	منتظر گذار مدیریتی published بمانید. اگر مجموعه بسته عوض شده باشد، انتشار با رد امن شکست می‌خورد
published	برای تغییر، بازبینی یا نسخهٔ تازه منتشر کنید. برای برگشت به محتوای سالم قبلی، مقصد فعال را به نمونهٔ واجد شرایطی بازگردانید که هنوز published است
yanked یا suspended	این وضعیت‌ها با گذار دوباره فعال نمی‌شوند. مقصد تازه‌ای منتشر کنید یا به مقصد published دیگری بازگردید. خارج‌کردن، آن نسخه را از فهرست مقصدهای بازگشت هم بیرون می‌برد — بازگشت مقصدی می‌خواهد که هنوز published باشد — پس خارج‌کردنِ آخرین نسخهٔ سالم چیزی برای بازگشت باقی نمی‌گذارد
تعارض چکیدهٔ نسخهٔ ثابت یا بسته	متوقف شوید. شناسهٔ مقصد و مجموعه بسته را بررسی کنید. چکیده را بازنویسی نکنید؛ در صورت تغییر واقعی محتوا مقصد تغییرناپذیر تازه بسازید

retry برای bundleهای Environment و App عمداً به محتوا مقید است. هیچ شناسهٔ revision نسازید یا به فرمان ندهید. اگر بایت‌های build تغییر کرده‌اند، alamr build و alamr test محصول‌ویژه را دوباره اجرا کنید؛ CLI فقط مقصد تغییرناپذیر مشروع همان بایت‌های دقیق را می‌سازد یا انتخاب می‌کند. تغییر بی‌اثر مانیفست هرگز راه‌حل مجاز تعارض نیست.

اثر پس‌گرفتن و تعلیق بر زمان اجرا#

yanked و suspended هر دو گذار مدیریتی و نهایی از published هستند. گذار دلیل می‌خواهد و در گزارش ممیزی ثبت می‌شود.

• برای revision یک Environment، Registry آن را به‌عنوان bundle نگه‌داری‌شدهٔ فعال کنار می‌گذارد و sessionهای Runtime و Grantهای Plugin مرتبط را باطل می‌کند.
• برای نسخهٔ پلاگین، رجیستری آن را از حالت فعال خارج و مجوزهای صادرشدهٔ پلاگین برای همان نسخه را باطل می‌کند.
• برای بازبینی استقرار، رجیستری استقرار را تعلیق و مجوزهای پلاگین آن را باطل می‌کند.

نسخهٔ ثابت اصلی، رکورد بازبینی و مدرک publishedAt باقی می‌مانند. برای نسخهٔ yanked قفل‌های صحت قبلی تکرارپذیر می‌مانند، اما alamr add نصب تازهٔ آن نسخه را رد می‌کند.

بازگردانی بدون بازنویسی تاریخ#

بازگردانی برای revisionهای Environment و App و releaseهای Plugin پشتیبانی می‌شود. اشاره‌گر فعال پروژه را به مقصدی می‌برد که:

• به همان پروژه تعلق دارد؛
• هنوز وضعیت published دارد؛
• زیر مسدودسازی اضطراری فعال نیست.

بازگردانی دلیل می‌خواهد و در گزارش ممیزی ثبت می‌شود. مقصد، بازبینی، بسته یا درخواست قبلی را ویرایش نمی‌کند. rollback یک Environment یا App، bundle نگه‌داری‌شده و بررسی‌شدهٔ revision انتخابی را فعال می‌کند؛ rollback اپ پیش از جابه‌جایی اشاره‌گر منتشرشده، همان bundle تغییرناپذیر را دوباره اعتبارسنجی می‌کند. Registry مقصد تغییرناپذیر و رکورد انتشار را قفل می‌کند، واجدشرایط‌بودن جاری را دوباره می‌سنجد و اشاره‌گر را در همان تراکنش جابه‌جا می‌کند. بنابراین yank، retire یا مسدودسازی اضطراری مستقیم/وابسته به artifact در حالت هم‌زمان یک برندهٔ ترتیبی دارد و rollback نمی‌تواند مقصدی را فعال کند که بین برنامه‌ریزی و به‌روزرسانی اشاره‌گر دیگر واجد شرایط نیست.

برای بررسی و ذخیرهٔ برنامهٔ مقید به چکیده از alamr rollback <environment_revision|app_revision|plugin_release> <targetId> --reason <text> --plan استفاده کنید و سپس همان برنامهٔ دقیق را با تأیید صریح اعمال کنید. API مستند مدیریت و کنسول همان عملیات Registry را صدا می‌زنند؛ هرگز با ویرایش شناسه، چکیده، مانیفست یا فایل قفل بازگردانی را شبیه‌سازی نکنید.

برای تشخیص خطا عیب‌یابی، برای تعریف اصطلاحات واژه‌نامهٔ محصول و امنیت و برای قرارداد دقیق مرجع API را بخوانید.