There is a similar issue with products in #245. This new implementation will fix it, and we're adding a similar one for gateways. Should be in the next major release.

I have my doubts that the proposed changes actually resolve this issue.
Let me share my train of thought and feel free to correct me if I am wrong.
Every addition of an API contains a changed file in the self-hosted gateway folder, so this is all good. The publisher considers them during publishing of the git commit.
However, since I don't want to have the new API associated with the existing managed gateway, there are no file changes in the managed gateway folder, so the publisher is still not going to consider them.
How is the proposed change addressing this?

I'm not sure what your baseline is, so I'll make some assumptions and walk through a few scenarios.

Let's say you start with a managed and self-hosted gateway in the portal. You have zero APIs. You run the extractor. Your folder structure will be:

• artifacts
  • gateways
    • managed
      • gatewayInformation.json
    • self-hosted
      • gatewayInformation.json

You then go to the Azure portal, create APIs A and B, assign API A to the managed gateway, and API B to the self-hosted gateway. You run the extractor. Your folder structure will be:

• artifacts
  • gateways
    • managed
      • gatewayInformation.json
      • apis
        • apiA
          • gatewayApiInformation.json
    • self-hosted
      • gatewayInformation.json
      • apis
        • apiB
          • gatewayApiInformation.json
  • apis
    • apiA
      • apiInformation.json
    • apiB
      • apiInformation.json

You then decide to do a code-first deployment: instead of making changes via the portal & extracting, you want to change the git artifacts and publish that commit. In this change, you remove API A from the managed gateway, add a new API C to the self-hosted gateway, and add a new API D that won't be associated with any gateways. Your folder should look like this:

• artifacts
  • gateways
    • managed
      • gatewayInformation.json
    • self-hosted
      • gatewayInformation.json
      • apis
        • apiB
          • gatewayApiInformation.json
        • apiC
          • gatewayApiInformation.json
  • apis
    • apiA
      • apiInformation.json
    • apiB
      • apiInformation.json
    • apiC
      • apiInformation.json
    • apiD
      • apiInformation.json

The publisher will detect the following changes and make them accordingly when it runs:

• artifacts/apis/apiC/apiInformation.json was created. API C will be created in APIM.
• artifacts/apis/apiD/apiInformation.json was created. API D will be created in APIM.
• artifacts/gateways/managed/apis/apiA/gatewayApiInformation.json was deleted. API A will be removed from the managed gateway.
• artifacts/gateways/self-hosted/apis/apiC/gatewayApiInformation.json was created. API C will be added to the self-hosted gateway.

Does that make sense? Let me know if I'm missing something.

Something just clicked for me; I misread your initial question. When you talk about the "managed" gateway, you're not referring to a gateway you create called "managed". You're referring to the built-in managed gateway.

If that's the case, I doubt there's functionality to manage that "managed" gateway. You can't export it as an artifact and "manage" it. You can assign APIs to a self-hosted gateway using the methods described in the previous comment, but I'm not aware of a way to also disassociate them explicitly from the built-in gateway.

I would suggest creating a support ticket and asking whether that's possible (outside of our tools). If they show you how to do it, we can see if the steps are achievable through our tools.

Yes, I am talking about the built-in managed gateway. Sorry for the missing clarity.

I actually experimented and simply created a folder called "Managed" and added an apis.json that has an empty array in it.
When I use the publisher without the COMMIT_ID it actually disassociates the APIs from the built-in gateway.
But as I said, this does not work when only looking at changes within a git commit.

Can you elaborate on what you're seeing? How do you know they're no longer associated with the built-in gateway?

You can see the assigned built-in gateway when you have a look into the API in the portal.
The field "Gateways" either contains the "Managed" + your custom ones, or only the custom ones after I tested it.

Thanks for the information - makes sense now. I think our implementation will partially handle your scenario.

When the extractor runs, it queries APIM for a list of gateways. It then loops through all gateways and exports their associated APIs. The problem is that APIM's list of gateways does not include the managed gateway. We would have to add a step to explicitly ask for the managed gateway's APIs. The APIs would then show up in artifacts/gateways/managed/apis/....

Adding to our backlog for further investigation.

@daviian feel to submit a PR and we can merge accordingly.

Thanks for the information - makes sense now. I think our implementation will partially handle your scenario.

When the extractor runs, it queries APIM for a list of gateways. It then loops through all gateways and exports their associated APIs. The problem is that APIM's list of gateways does not include the managed gateway. We would have to add a step to explicitly ask for the managed gateway's APIs. The APIs would then show up in artifacts/gateways/managed/apis/....

Adding to our backlog for further investigation.

I suppose this also needs to be done in the publisher? Otherwise the built-in managed gateway is always assigned automatically.

@guythetechie - I've had a look into it and locally it looks good so far. However, there is one point I have concerns about.
The APIM API documentation Gateway Api - Create Or Update and Gateway Api - List By Service excludes "managed" from being an allowed value ("Must not have value 'managed'").
However, both APIs work as intended for our use case when passing "managed". Additionally this API is also used from the APIM Portal when assigning/removing APIs from the managed gateway, so I assume the API documentation requires an update.
The only API that returns a validation error is Gateway - Get, so I conditionally exclude fetching the gateway details for the "managed" gateway.

What are your thoughts on this? If you like I can create the PR so that you can have a preliminary look as well.

EDIT:
There has been a similar question https://learn.microsoft.com/en-us/answers/questions/624766/azure-apim-gateways-and-bicep that has not been answered since quite a while.

@guythetechie @waelkdouh Any update? Anything I can do/provide to help out and create some progress?