Convert Callers

Convert Callers

Convert callers is the last stage of a wave page. It converts the wave's pipelines to GitHub Actions in each destination org. When a source builds building blocks, Building blocks ready comes before it: a gate that holds the callers until the building blocks they call are ready. This page covers both stages.

On Convert callers, set the conversion up in each destination org, then start converting. Setting up shares the building blocks the wave's pipelines call from the building block home, and maps each ready family's callers onto them. See Mappings onto Building Blocks. Nothing runs until you start converting.

Building Blocks Ready

Building blocks ready is a gate, not a build step. The work happens in the building block releases. Building block plan opens Build Building Blocks.

The stage card reads N of M families are ready to convert, and warns while the gate is shut. See When Callers Can Convert for what opens it. Before building blocks are planned, the card reads Known once building blocks are planned. Once the plan has some, a wave that needs none reads None needed: nothing holds its callers back here. When only one-offs call building blocks here, the card reads One-off builders ready, N one-off builders not ready, or Artifact type not known for N one-offs. See One-Off Pipelines.

The stage says when this wave's callers start converting, how many building blocks they need, and the building block home those are built in. Each item that has to hold is marked met or not. Each family shows how many of its building blocks are ready, and Ready to convert or Waiting. Waiting lists why, the first three reasons and then how many more.

The table lists each building block, its status, the release it is built in, and the date it is ready by. A release built for another wave names that wave. Click a building block's name to open its blueprint in the building block home. See Open a Building Block's Blueprint.

If a building block finishes after those callers start, the stage warns you. Move the wave on Schedule Waves, or give that release an earlier due date on Build building blocks. When the plan builds every building block in one release (All up front), move the wave, or switch to As waves need them.

Waiting on an Org

The card reads Waiting on the building block home while that home is not connected, even when a destination org also cannot use building blocks. Otherwise it reads Waiting on a destination org that cannot use building blocks, and names one of them if several cannot. With no home yet it reads Waiting on a building block home. With no destination yet it reads Waiting on a destination org.

Connect the home, or connect the destination. A destination also has to have Building Blocks on its plan, as When Callers Can Convert lists.

While the home is connected and every destination can use building blocks, the card counts how many families are ready to convert.

When Callers Can Convert

When a wave's callers need building blocks, they convert only once a gate opens. It opens per pipeline family: a family is ready to convert when every building block it needs is ready and can be called from the orgs that family's callers move to, even while the rest of its release is still being built. Callers may convert when every item below holds. The wave does not wait for every family. One that is ready to convert is enough. A wave that needs no building blocks has no gate.

• The plan has a building block home, and that home is connected.
• At least one family's building blocks are all ready: registered in the home.
• At least one ready family's building blocks can be called from the orgs its callers move to, and by the repositories calling them.
• Every destination org of the wave can use building blocks: it is connected, and Building Blocks is available on its plan. If it is not, contact that org's CodeCargo administrator. A wave with no destination org yet fails this until you assign one.

A family that is not ready to convert says why. Connect a destination that is not connected yet, or give its callers a destination. Until then the family is held, and its building blocks are not judged. If a building block has no repository, or that repository is not active in CodeCargo, set where it is built on its blueprint in the home.

Who can call an action or a workflow:

• A public repository can be called from anywhere.
• In the caller's own org, share the repository's Actions with the org or the enterprise.
• From another org in the same enterprise, share its Actions across the enterprise. The repository can be private or internal.
• An org outside that enterprise can call it only when the repository is public.

GitHub also limits which repositories may call it. Only a private repository can call a private repository's actions or workflows. A private or internal repository can call an internal one's. A public repository can call neither. When the reason asks you to, change the building block repository's visibility, or the visibility of the repositories calling it.

The plan judges the GitHub copy, not the source. A copy that already exists counts, including one moved before this wave. Otherwise it uses the visibility the move will give the copy. Until the move holds a calling repository, that caller does not keep the family waiting. A Jenkins job the plan places in a target repository is judged by that repository, once it exists.

A repository building block is read, not called, so Actions sharing and who calls it do not matter. Any repository in the caller's own org works, or an internal repository in the caller's enterprise. Otherwise make it internal to that enterprise, or public.

When repositories move first, the convert step also lists Building blocks are ready before callers start. When repositories and pipelines move together, that item is on the wave's ready list. It is about dates, not whether the blocks are built: it is met when no release this wave needs is due after its callers start. The same fact is on What needs attention.

When a Family's Building Blocks Aren't Planned

A family whose pipelines need building blocks and that is not planned yet is never ready. Its callers wait. The reason says that family's building blocks aren't planned yet, and to plan them on Review pipeline families. Other families in the wave are not held.

A family that already has building blocks counts as planned. It does not hold its callers while you plan it again.

One-Off Pipelines

At SLSA Build level 3, this stage also lists the type builders that the wave's one-offs call. See One-Off Pipelines at Build Level 3 for what a one-off is and when it waits on them.

A one-off that Convert callers still asks about is counted here, with a Convert callers link that opens that stage. One whose copy the scan has not read yet is counted apart, and so is one Convert callers neither asks about nor waits on. See What These One-Offs Publish.

Set Up the Conversion

Under Set up in each destination org, the page says how many orgs are set up and which cannot be set up yet. Set up the conversion gives each destination org that can take it a wave of its own, named for this one, such as Wave 1 · Data platform (migration plan). It takes this wave's conversion style, the plan's replacements, and the plan's directives followed by this wave's, and it holds the pipelines that can convert there now. Nothing runs there until you choose Start converting.

Left out are Jenkins jobs when the plan does not convert Jenkins or the org has not linked them to their moved repository, pipelines whose repository has not moved, pipelines waiting on building blocks, pipelines not in the destination yet, and pipelines already in another wave there. A pipeline that calls more than one family waits for every one of them. See Pipelines That Call More Than One Family and A Wave the Plan Converts.

You do not import the plan's Azure DevOps pipelines in a destination org first. Starting the wave's rewire, setting up the conversion, and Start converting each copy the sandbox's Azure DevOps pipeline import into each destination org, for the repositories the plan moved there:

• The copy links each pipeline to its moved repository.
• It brings each project's service connections, variable-group keys, and secure files with the mappings they have in the sandbox, so map credentials there. A credential with no mapping in the sandbox takes the default mapping an import gives it. A non-secret variable-group key becomes a GitHub variable named after it, as Credential Mappings describes.
• The copies are the plan's, not the org's own import. They aren't listed on the destination's import or Pipelines pages, though its plan wave and its Prepare for rewire use them. A pipeline the destination imported itself counts too.
• Nothing is copied while the destination is importing that Azure DevOps organization. See Start Converting.

Jenkins jobs are different: a Jenkins job is left out until that org imports it.

What keeps you from setting up at all is listed before you click. While any of it applies, setting up would be refused in every org at once, so the button is not offered.

Set up again adds pipelines the plan would now take into an org's wave, shares building blocks the home stopped sharing, and retries an org where setting up failed. It is not offered while setting up is still running, or when nothing new would be written.

Which Orgs Can Be Set Up

An org that cannot be set up is skipped, and its card says why. The others are still set up. If none can, there is no button.

An org can be set up when:

• Its move has settled into one CodeCargo organization and copied at least one repository.
• It is connected. Its Azure DevOps pipelines come from the sandbox's import, as Set Up the Conversion says. Jenkins jobs still have to be imported here.
• Migration Assistant is available on its plan. If it is not, contact that org's CodeCargo administrator.
• When families need building blocks, that org passes the Building blocks ready gate.
• The plan has enough pipeline conversions left for what setting up would newly add. Orgs on the same plan share what is left. Pipelines already waiting to convert in plan waves on that plan count. An org that would add none is not refused.

Start Converting

Start converting stays unavailable until an org is set up, and while setting up is still running.

Once a destination org is set up, choose Start converting. CodeCargo copies the sandbox's pipeline import in again, then batches the pipelines the plan admits now and starts those batches as you, in that org's wave. An org that is not set up, is still setting up, failed, or is still importing is skipped and says why. If it is importing an Azure DevOps organization its pipelines come from, start converting again once that import finishes. Choose Set up again for one that failed. An org where you cannot start converting is skipped the same way. The others still convert.

Choose the orgs, then every ready family, or only the families you choose. Include the one-offs on their own or with the families. Pilot mode: start only a sample of each family starts only a sample of each family that has not started yet. Set the Sample size per family, 3 to start with and at most 50. The rest wait for a later start. A pilot doesn't sample one-offs: every one-off included converts now. Pilot mode does not start a full batch that is already waiting; start converting without it to start that batch.

Starting again is safe. A family is skipped once every pipeline the plan admits was dispatched. Pipelines admitted since the first batch get a batch of their own. A batch that dispatched no one is waiting for its pipelines to be linked to their repositories. A Jenkins job is linked by an import in that org. An Azure DevOps pipeline is linked by an import in that org, or by the plan's copy of the sandbox's import. Start converting again once they are linked. A family whose building blocks are not ready yet is skipped.

The batch is named for the wave and the family. A pilot batch adds Pilot. A later batch of the same family adds (the rest).

Before those batches start, the wave's CargoWall mode is applied to the repositories the pipelines convert:

• A repository that already has its own mode keeps it.
• When the org is on Enforce and the wave is on Audit, the repository is not set to audit. It keeps the org's mode.
• When the wave is on Enforce and the org is on Audit, a repository that does not already have its own mode is set to Enforce.
• The org's own mode is never changed. A repository that would only repeat the org's mode is left to take it. A repository an earlier start set, and nobody has changed, follows the wave the next time, including back to the org's mode when the wave matches it or CargoWall is off for the wave.

A pull request for a converted Azure DevOps pipeline says: "The Azure DevOps pipeline keeps running until the migration plan's Close out disables it." Merging is that pipeline's cut-over. The pipeline and the workflow both run on the same pushes until Close out disables the definition. A pull request for any other pipeline does not get this line.

Each Destination Org

Each card reads Not set up, Setting up, Failed, Waiting, Ready to convert, Converting, or Converged. Once a batch converts pipelines there, the card counts how many headed to that org have converged, and how many settled without converting. Above the cards, the wave counts how many of its pipelines have converged.

• While a converged pipeline's Azure DevOps definition is still enabled, the card links to Close out.
• The card says what the org's wave holds and what it left out. Each family shows how many pipelines it holds, whether it is ready to convert, whether a pilot or the full batch has started, and what it waits on. Pipelines that may not reach SLSA Build L3 are named, with why.
• When the org can no longer call building blocks the home stopped sharing, the card says so. Set up again shares them. Open the wave in the org opens that org's wave.

How Conversion Is Going

On the journey, when the plan converts pipelines, a separate convert step stays upcoming until a batch converts any of the wave's pipelines. Once one does, the step shows how many have converged, and it is due at the end of the convert window. When the wave has one window, it follows the move first. After that move is done, it stays in progress until the pipelines convert, and the converged counts start once a batch converts any of them.

Converged means the same thing as Close out: the pipeline is migrated, or done externally. The step counts the pipelines the plan matched to the wave's repositories, Jenkins jobs included when the plan converts them. A pipeline still counts as converged when Close out has not disabled its Azure DevOps definition yet.

• It reads Needs you while a pipeline has failed, is blocked, waits on an answer, or was canceled in its destination org.
• It is Done when every pipeline that still converts has converged.
• A pipeline you skipped, or mapped onto an existing workflow, settled without converting. It is left out of what still converts, so it does not hold the wave short. Close out leaves that definition running.
• A pipeline that is not in its destination org yet, or whose org's conversion has not started, still counts. The step is not done while any of those remain.

Start converting the families that are ready with Start Converting.

Families in This Wave

Once the plan has pipeline families, this wave's families are bars on Convert callers. The ten biggest are drawn against the largest. The heading reads Biggest 10 of 24 families, or 4 families when every family is a bar. Choose a family to open this wave's repositories whose pipelines belong to it. The count on the bar is the same number that family shows for this wave on Review pipeline families: every pipeline in this wave that calls the family, so a pipeline that calls two families counts on both bars. The card counts each pipeline once. See Pipelines That Call More Than One Family.

Any other families sit behind 14 more families, 30 pipelines. Open that line to read them 15 at a time, biggest first. When this wave converts pipelines in no family, 3 one-off pipelines follows, outside any family, converted one by one. That line is hidden when there are none.

Until a batch converts any of this wave's pipelines, the Convert callers card reads 12 pipelines in 4 families, or 3 pipelines when every one in this wave is a one-off. That count is the pipelines the plan converts here, not every pipeline definition the wave's repositories hold. Until family analysis finds any families, the stage does not list them and the card keeps the definitions count. It keeps that count when this wave converts none of its pipelines, too.

What These One-Offs Publish

When SLSA provenance is on at Build level 3, Convert callers lists one-offs the discovery scan could not read. Until someone answers what it publishes, the wave holds it and does not convert it inline. The section is hidden when the wave has none of these, answered or not.

The summary counts the whole wave: how many still wait, or that each has an answer. One-offs still waiting on the discovery scan of their copies are named apart. The plan asks about those only if that scan cannot read what they publish.

Each row names the one-off, its repository, its destination org, and its answer, or Not answered yet. Choose Answer, pick every kind it publishes, and Save. The kinds are a container image, an npm package, a Maven package, a NuGet package, a Python package, and release files. It publishes nothing is a valid answer and clears the kinds. Change starts from the answer already saved. Clear takes it back. A toast offers Undo until you use it or close it.

Your answer holds in every destination org, and a later scan does not change it. Builders for a new answer are added the next time building blocks are planned. A one-off that publishes something converts once those builders are ready.

• Select rows on the page and choose Answer N selected to give them one answer. Saving replaces an answer some of them already have, and the dialog says how many.
• When every row on the page is selected and more match, Select all N matching covers every page. Saving asks you to confirm that count. Narrow the list to 5,000 or fewer to answer them all together.
• Unanswered shows only rows that still wait, across every page. Once the list runs past 25, search by one-off or repository name. The summary still counts the whole wave.

Answering or clearing needs the Migration Assistant manage permission. Without it, the section still shows each answer and offers nothing to change.

Jenkins Jobs in a Wave

When the plan converts Jenkins jobs, they count among the wave's pipelines. A job follows the repository its git URL names. The wave names them with the pipeline count, such as 16 pipelines, 4 of them Jenkins jobs. When every pipeline is a job, it reads 6 Jenkins jobs. The Convert callers stage says the same thing: 16 pipelines convert to GitHub Actions in this wave, 4 of them Jenkins jobs.

Ready to convert when includes Every org's Jenkins jobs are imported. The orgs still left are listed under that row. Hover one for the Jenkins instance and how many jobs are not imported yet. Import them in that org. The row links to Plan the Org Layout, where Import opens the import page. The row stays open until every one of those jobs is imported.

The move and the rewire do not list this item, and preparing or starting the move does not wait on it. When repositories and pipelines move in one window, the item is on the wave's ready list and does not keep the wave from starting.

Jenkins Jobs with No Repository the Plan Moves

A Jenkins job that does not belong to a repository the plan moves converts where you placed it on Review pipeline families: a folder, the instance's top level, or a pin. Setting up the wave's conversion admits it in that destination org and links the org's own job to the target repository, an active repository of that name. That includes an org the wave moves no repository into.

That org does not wait on a move. It has to be connected, with CodeCargo installed, and the jobs imported. Until then, that org cannot be set up, and its card says why. The other conversion gates still apply. Ready to convert when names each Jenkins instance these jobs come from. The move does not wait on that import.

The job waits on its family's building blocks, and a one-off waits on its type builders, in the org it goes to. It does not wait on a move or a reference. It counts in the wave's conversion, which is not done until it converges.

• The org has no active repository of the target name. The job is left out. The schedule says that org doesn't have the target repository. Create the repository, or pick a name the org already has, then choose Set up again.
• A person or the import already linked the job. That link is kept. Linked to the target, the job converts. Linked to another repository, the job is left out as not linked to the repository it converts in.
• You change the target after the conversion wrote the link. The link follows the new target until a batch converts the job. A link a person set stays. Once a batch has converted the job, the conversion leaves its link where it is, and the job is left out until that link is the target.

The conversion does not set a CargoWall mode on the target repository. Its mode stays what its people set.

When a Pipeline Reads a Repository That Isn't in GitHub Yet

Setting up a wave's conversion leaves a pipeline out when its repository reads a repository that isn't in GitHub yet. The converted workflow would check that repository out, use it as a template or a repository resource, include it as a submodule, or download its pipeline artifacts, and would have nothing in GitHub to point at. Other pipelines in the wave still convert. A trigger, a hard-coded URL, or an Azure CLI call does not hold the pipeline.

If it reads more than one, the first of these that applies is what it waits on:

• The plan has not decided a destination or a wave for one of them. The pipeline waits until you decide both. Assign them on Plan Repositories, then choose Set up again.
• One is not in GitHub yet and moves in a known wave, including a repository headed to another org that has not arrived there. The pipeline waits for that move, until the last such wave. Move it into this wave or an earlier one on Review Dependencies, or choose Set up again once it is in GitHub.

A repository that stays on Azure DevOps does not hold the pipeline; the workflow reads it there through the service connection. See Stays in Azure DevOps. A repository already copied into the org the plan sends it to does not hold the pipeline either.