Strategy to promote apis from QA to Prod in a Mono Repo Environment

[Mohid-A]

Release version

v4.5.0

Question Details

Hi,

We maintain a single mono repo that includes all the APIs in a single repository. We are often running into challenges while pushing the APIs from QA to Prod, as with the approach publish-artifacts-in-last-commit, often commit includes multiple API'S changes not only just one that needs to be pushed to Prod. With publish-all-artifacts-in-repo, many APIs are in QA testing that should not go to prod.

When an API is fully tested in QA and ready to move to Prod. I am manually exporting the API spec, and policies, then deleting them from the lower environment, so that the next extractor picks up and using the last commit-based publisher strategy pushes it back to prod.

I went through and understand the strategies mentioned here separating the repositories by teams, etc https://azure.github.io/apiops/apiops/6-supportingIndependentAPITeams/

With the workspaces are still in preview. Can you please suggest the best strategy to deal with my scenario? Is there a way to tell the publisher to promote only specific APIs, and their associated artifacts?

Expected behavior

To be able to configure publish to pick specific APIs without publish all the artifacts from the given commit or all repo artifacts from the repository publishing

Actual behavior

With a commit-based push, often changes on the commit include multiple APIs that are not ready to push to Prod.

Reproduction Steps

Default steps to run the publisher pipeline by commit or publish all artifacts from the artifact folder.

[github-actions]

  Thank you for opening this issue! Please be patient while we will look into it and get back to you as this is an open source project. In the meantime make sure you take a look at the [closed issues](https://github.com/Azure/apiops/issues?q=is%3Aissue+is%3Aclosed) in case your question has already been answered. Don't forget to provide any additional information if needed (e.g. scrubbed logs, detailed feature requests,etc.).
  Whenever it's feasible, please don't hesitate to send a Pull Request (PR) our way. We'd greatly appreciate it, and we'll gladly assess and incorporate your changes.

[waelkdouh]

Duplicate #401