microsoft/apm

Describe the bug The stale-file cleanup diagnostic presents a dependency key as though it were the filesystem location from which files were deleted: f"Cleaned {count} stale {noun} from {dep_key}" For an absolute local-path dependency, the displayed path identifies the source package even though cleanup occurs under the deployment root. A before/after inventory confirms that the source remains unchanged. To Reproduce Create a local-path package containing a skill and an ignored generated file. Install it globally with --target agent-skills. Uninstall it by its _local/<name> key. Observe output such as: Cleaned 6 stale files from /absolute/path/to/source The source tree remains unchanged; /absolute/path/to/source is the dependency identifier passed as dep_key, not the deletion location. Expected behavior The diagnostic should not describe a dependency identifier as a deletion location. It can report the package relationship directly: Cleaned 6 stale deployed files for _local/source

What happened apm install/apm update fails on Windows with: Failed to download dependency <owner>/<repo>: Failed to clone repository: git executable not found on PATH. Please install git: https://git-scm.com/downloads ...even when git is installed and resolvable on PATH (verified with git --version / (Get-Command git).Source in the same shell, in both Git Bash and native PowerShell). Root cause apm_cli/utils/git_env.py, in _resolve_trusted_executable(): candidate = shutil.which(str(directory / name)) On Windows, shutil.which() only appends PATHEXT extensions (.EXE, .CMD, …) when the given command has no directory component. Once you join a directory onto the name (str(directory / name)), shutil.which takes the "already a path" branch and checks the literal string for an exact, executable match — it never tries git.exe, git.EXE, etc. Since the file on disk is git.exe and never a bare git, the check always fails, for every directory on PATH, regardless of whether Git is installed. M

Describe the bug The Lifecycle hooks doc only references the admin tier file path for Linux, /etc/apm/policy.d/*.json. This should be updated to include Windows. apm/src/apm_cli/core/lifecycle_scripts.py Lines 346 to 351 in 8993dcc def _get_policy_scripts_dir() -> Path: """Return the platform-specific policy scripts directory.""" system = platform.system() if system == "Windows": return Path(r"C:\ProgramData\APM\policy.d") return Path("/etc/apm/policy.d")

Description PR #2382 (fixing #2368) added set_authorization_header_git_env() / set_ado_bearer_git_env() in src/apm_cli/utils/github_host.py. These rewrite the indexed GIT_CONFIG_{COUNT,KEY_N,VALUE_N} env-var set in place: existing auth-channel entries are stripped, everything else is preserved and re-indexed, and the new Authorization header is appended last. That retain/reindex predicate intentionally mirrors the pre-existing AuthResolver._clear_git_auth_env in src/apm_cli/core/auth.py (same policy: an entry whose key contains extraheader, or whose value is an Authorization: header, is dropped; everything else is retained and re-indexed). This is a genuine split authority per .apm/instructions/architecture.instructions.md: the SAME decision ("which GIT_CONFIG_* entries are auth-channel entries to strip") is now implemented in two places. If the predicate ever needs to change (e.g. a new auth-channel key pattern), only one site is likely to get patched, and the two will silently drift.

Is your feature request related to a problem? Please describe. APM distribution is currently centered around Git-based package sources and local packed artifacts. That works well for source-centric workflows, but it is a poor fit for enterprise environments that standardize on OCI registries for artifact storage, promotion, access control, and mirroring. In particular, I would like to consume APM packages from OCI in apm.yml, either alongside or instead of current Git-based dependencies. I also want this to work without hard-coding a specific registry host into package definitions, since enterprise deployments often rely on proxies, mirrors, or internal registry indirection. Describe the solution you'd like Add native OCI registry support for APM packages and bundles. Specifically, I would like: a way to publish APM packages or packed bundles to OCI registries a way to install or unpack APM packages directly from OCI digest-pinned installs for reproducibility standard OCI authenticati