When a delivery doesn't finish

A delivery updates each configuration item in turn. It works out an order that puts everything an item needs ahead of the item itself. Most of the time everything goes through. Sometimes a few items don't, and the delivery tells you which ones and why.

Partly done is a normal outcome

Mochi reports what actually happened: “Mostly done”, with “17 of 19 items · 2 didn't land” beside it, rather than a single pass-or-fail verdict. The items that went through are genuinely in that environment. Open the delivery to see every item and what happened to it.

An item is waiting on something

Most hold-ups are about something an item points at. There are three of them, and the fix is different each time, so read which one it says.

• Waiting on something in this delivery that didn't go through. Mochi names the item further up the list that didn't make it, and this item needs it. Sort that one out and this one follows on the next attempt. There's nothing to do about this item itself.
• Needs something that isn't in this delivery. The item points at a field, group or category that the target environment doesn't have and this change set doesn't bring. Mochi names what's missing. Add it to a change set and send it along.
• Points at something that no longer exists. The item refers to something that isn't in the environment you're moving it from either. Mochi says how many, and of what kind. That's a broken reference. Nothing about this delivery can fix that; repair it where the configuration lives, then move it.

Some settings can't change once an item exists

A few things about an item are fixed the moment it's created: a field's type, how it handles languages, and where it applies. If one of those differs between environments, the only way to make them match would be to remove the item and build it again, which would take everything already stored in it with it.

Mochi won't do that on its own. It stops, names the one setting that can't change, and leaves the decision to you. Either make that change directly in the target environment, or remove and re-add the item deliberately.

Aprimo refused some items

Some items Aprimo turns down on its own terms, not because of anything in your configuration: user groups, which only an operator may create; Aprimo's own setting definitions, the ones with dots in their names; fields that come with an Aprimo feature and are looked after by it. The run lists these under Aprimo refused N items, with what Aprimo said about each one.

There's one thing to do about them: choose Mark as managed by Aprimo. Marked items leave deliveries and stop being tracked, through a change set like any other (see Managed by Aprimo under Configuration). The delivery stays Failed until they're marked. Once they are, update the environment again and the next attempt lands.

A name or identifier that's already taken is a different hold-up. Some values have to be unique within an environment, and if something else there already uses one, the delivery leaves that item rather than pick a value for you.

A delivery that stopped, and the three ways to settle it

A delivery that stops at a safety check reads Blocked on its environment, with the reason. It doesn't hold the environment: nothing is running or waiting for approval, so New run on the pipeline stays available. A newer run overtakes it: as soon as the new one starts, the blocked delivery is called off with Replaced by a newer run on its history and has no actions left. Or settle it on its own page, in one of three ways.

On a pipeline that runs automatically, a blocked delivery waits for a person. The pipeline doesn't start another delivery to that stage on its own, so change sets that become part of your configuration in the meantime wait behind it. The environment's line says so: Blocked by 1 check failed · 3 change sets waiting. It moves again once someone tries the delivery again, sends it anyway, calls it off, or starts a new run.

• Try again. Adds another attempt to the same delivery, for the same change set. The earlier attempt is called off, and its history says it was tried again as a new run. Use it once whatever stopped the delivery has been put right.
• Update anyway. An admin sends the whole delivery through despite what the check found. Nothing is left out: an item that was changed directly in the environment gets only the settings this change set changes, so a direct edit to one of its other settings stays as it is (and still counts as a direct change for later runs). You're asked for a reason, and it's kept on the run.
• Call it off. This undoes nothing, because a delivery that stopped at a check hadn't sent anything yet. You're asked for a reason.

An attempt stays pinned to the change set it was started for. If a newer change set should reach the environment, choose New run on the pipeline and pick it.

Calling a delivery off

A delivery waiting to be approved holds its environment until someone acts on it, so nothing else can be sent there in the meantime. If it was started by mistake, or it's waiting on someone who isn't going to get to it, choose Call it off. Nothing has been sent yet, so nothing is undone. It just frees the environment up. You'll be asked why, and that stays on the history.

Turning down a delivery turns down that delivery. The change sets stay in your configuration and are part of the next delivery, which asks again. If you never want a change set, undo it.