Removed sandbox-api-repository topic to exclude from release automation

[hdamker]

Context

All CAMARA release automation tooling (Release Collector, release plan rollout campaigns, centralized linting) discovers API repositories by the sandbox-api-repository or incubating-api-repository GitHub topics.

The EdgeCloud repository still carries the sandbox-api-repository topic, but differs from standard API repositories in several ways:

• No rX.Y releases — only legacy-style releases (v0.9.3-rc, v0.8.1)
• Non-standard file structure — centralized linting (PR admin: migrate to centralized linting workflows #388) cannot be applied without restructuring
• Umbrella repository — the individual APIs have already been split into dedicated repositories (SimpleEdgeDiscovery, TrafficInfluence, ApplicationEndpointDiscovery, ApplicationEndpointRegistration, OptimalEdgeDiscovery), all of which participate in release automation successfully
• One remaining API (Edge Application Management) — as discussed in admin: migrate to centralized linting workflows #388 (comment), moving this into a dedicated repository would be the cleanest path forward

As a result, automated campaigns fail or produce incorrect results for this repository (e.g., the recent release-plan rollout and release-info-sync campaigns).

Proposed action

Subject to approval by the Release Management working group, the proposal is to remove the sandbox-api-repository topic from EdgeCloud. This would:

• Exclude the repository from Release Collector runs and all bulk campaigns
• Have no impact on the 5 split-out repositories, which have their own topics and continue to work normally
• The camara-sp-edge-cloud topic would remain, preserving the sub-project grouping

Once Edge Application Management is moved to its own dedicated repository (with proper topic and structure), it will automatically be picked up by the automation.

References

• PR admin: migrate to centralized linting workflows #388 — centralized linting blocked by non-standard structure
• Release plan rollout campaign — EdgeCloud was the only repository that failed (label pagination issue triggered by 32+ labels)

[hdamker]

Based on the decision taken in ReleaseManagement (camaraproject/ReleaseManagement#387 (comment)) I removed the sandbox-api-repository topic from the repository.

The recommendation is to request a new repository for edge-application-management.yaml

[Kevsy]

@camaraproject/edge-cloud_codeowners ^ please see above recommendation to request a new repository. I will create the issue in API Backlog tomorrow unless there are any objections.

[JoseMConde]

Thanks @Kevsy @hdamker , I have pending to ask API Backlog to create this new repository of EAM, but I was waiting until we have all the PRs related with this API approved and merged, because I remember that in the past when we created the repositories for the other APIs we couldn't transfer the PRs, we could only transfer the issues, so if you want to create this repository now, for me it is not a problem at all, quite the opposite I think is something that we need to have ASAP, but I am afraid of losing some info for the open PRs.

[hdamker]

@JoseMConde sure, getting all valuable contributions merged before the transfer makes sense (nevertheless they can also be recreated by authors - might be an option for stale ones to see if there is still interest). It also makes sense to tag the transferred commit on main branch before the transfer (or use the commit url for reference in the new repo).

[Kevsy]

@JoseMConde OK I'll wait for confirmation regarding open PRs before proceeding

[hdamker]

@JoseMConde OK I'll wait for confirmation regarding open PRs before proceeding

@Kevsy @JoseMConde I propose to ask for the new repository in parallel. When and how to transfer the existing assets into the new repository is an independent decision in my view.