Packaging Deployment

Establish actual boundaries

Identify repository root, Logic Apps host root, deployable runtime assets, dedicated tests, templates, local state, and intended package destination. The project may be at repository root or nested; do not require a solution-root layout.

Merge source-control exclusions relative to the actual .gitignore location. For a project-at-root layout, typical applicable entries are:

For nested projects, adapt paths or place scoped rules at the host root. Ensure nested secret copies are also ignored. Add actual generated output directories, not assumed logs/artifacts directories that do not exist. Preserve unrelated entries and verify effective exclusions, including existing tracked files: adding ignore rules does not remove a tracked secret or make its history safe.

The host-root .funcignore, not .gitignore, defines extra deployment exclusions. Merge applicable rules such as:

Adapt/add exact host-root-relative locations of tests, fixtures, request samples, docs, settings templates, reports, generated packages, and other non-runtime content inside the host root containing .funcignore. For example, for a host at repo\App, exclude repo\App\fixtures with fixtures/ in repo\App\.funcignore, not App/fixtures/. Folders outside the host root are already outside the package source. Do not use broad binary exclusions that would remove required runtime assemblies.

A placeholder-only settings template is optional. Document that the runtime does not consume it; configure local/cloud settings through the appropriate process. Exclude the template from deployment even if safe to track. It must never contain actual secrets. Do not copy .gitignore over .funcignore or replace existing user rules wholesale.

Validate before packaging

Require strict completed full-project validation immediately before release packaging:

When runtime validation is required by the task/repository, first establish readiness and complete the runtime-backed form against the intended target. Report actual blockers; do not disable warnings or claim an HTTP 202 accepted validation completed. Review existing validation failures without silently weakening the release gate.

Choose an output path outside the host root where feasible. A current-directory destination such as App.zip is outside a child App host; for a host at ".", choose an explicit external destination or verified exclusion. Create only the actual requested output parent.

Optional --manifest MANIFEST_PATH selects the manifest destination. Archive and manifest must be distinct files, including normalized paths/aliases. --force authorizes replacing reviewed output only; never use it to bypass invalid inputs or exclusions. An unreadable, non-file, or invalid UTF-8 .funcignore is an error, not empty policy.

The packager excludes local.settings.json case-insensitively, including nested copies, dedicated recognized native test/state content, and raw TRX. It refuses ambiguous mixed test/runtime roots rather than dropping runtime files. Dedicated native test intent is identified from project declarations, not merely a filename or state-directory marker. Do not rely on sensitive-data scanning to recognize every possible secret or custom artifact.

Inspect the actual ZIP and manifest

Require all requested workflow directories, host.json, connections.json when required, referenced parameters.json/runtime files, and necessary assemblies/artifacts. Verify the ZIP root is the host content, not an extra enclosing project directory.

Require absence of:

• local settings, credentials, signed URLs/keys, or secret-bearing exports;
• settings templates and non-runtime fixtures/tests;
• native private caches, test state, raw TRX, and test build output;
• logs, editor/workspace files, repository metadata, and runtime state;
• generated packages, nested archives, and inappropriate diagnostic reports.

Inspect using a read-only archive tool appropriate to the OS. Manifest exclusions are useful evidence but not a substitute for checking the archive. Ordinary runtime binaries may be necessary; do not exclude all bin, .dll, or .exe files indiscriminately.

Gate: Strict validation passed; exact archive/manifest inspected; only deployable content remains. Packaging success alone is not a deployment or secret-free attestation.

Deploy only within authorized scope

Confirm tenant/subscription, resource group, Standard app, environment/location, deployment route, and external effects. Azure services may incur charges. This preview does not establish production readiness. Do not create infrastructure as an unrequested side effect.

Prerequisites:

1. App and required resources exist, with compatible hosting/deployment configuration.
2. Managed identity is enabled by default through authorized provisioning; required local/cloud principals, connector access policies, and data-plane grants are verified.
3. Required app settings/parameters and managed connection wiring are configured without exposing values. Keep triggers from activating incomplete external dependencies.
4. Package and validation gates pass; relevant tests and deployment approvals are complete.
5. Deployment/recovery follows existing repository policy, including coordinated writers.

Use the existing pipeline when supplied. For authorized direct CLI ZIP deployment, the core Logic Apps command is available independently of extension packaging:

This is a core command, not an extension-owned deployment deploy command. Do not invent such a command. Core app-management/settings commands are also distinct from extension runtime APIs. Their existence does not broaden individual preview command support to Consumption, hybrid hosts, or deployment slots. Inspect target-specific support first.

Full application deployment publishes shared files and adds new cloud workflows. workflow set is only a separately approved replacement of one existing workflow on a writable target; it is not a substitute for deploying settings or a new app. Do not bypass run-from-package or read-only hosting restrictions.

Verify deployment separately

After acknowledged deployment:

1. Inspect the deployment result and actual workflow inventory.

2. Validate the local authored project against the deployed runtime when required:

   Copy

   az logicapp workflow validate --path App --all --fail-on-warning --with-runtime --resource-group GROUP --name APP --subscription SUBSCRIPTION_ID

3. Inspect deployed connection wiring and required authentication/access.

4. Exercise explicitly authorized representative workflows and verify outputs/effects; use actual supported run IDs and diagnose failed actions where history is available.

5. Verify excluded local files/secrets were not deployed using appropriate read-only inspection without printing secret contents.

Use the mandatory connections/live-operations procedures selected from SKILL.md before those phases. Runtime-template validation is not deployed-file equality, connection certification, or successful business execution; record each evidence type separately.

If deployment is partial, validation fails, resources remain, or effects are uncertain, report the actual state. Do not blindly retry, activate incomplete dependencies, delete retained resources, or claim guaranteed rollback.

Gate: Intended cloud content/configuration, completed required runtime validation, verified approved scenarios, exclusion evidence, and explicit remaining blockers.