Creation of a playground API repository for testing global workflows

[Kevsy]

Problem description

The 'live' testing of global workflows and potentially other global changes currently involves a CAMARA API repository. Testing of such changes risks delaying issue/PR resolution in that repository (I think I may have that problem in SimpleEdgeDiscovery at the moment, see here)

Expected action

Create a playground API repository with a dummy CAMARA API definition and artefacts, which conforms to API design guidelines, repository structure, etc. . This API will not form part of any meta release, it is purely for testing global workflows etc.

Additional context

We could continue to test on our private repos, but that risks missing any configuration or environment context which applies to the camaraproject GitHub organisation.

[iamdatanick]

I like this idea a lot, @Kevsy

[Kevsy]

@hdamker as requested in the TSC, here is the proposal in more detail:

1. the repository can be initiated with two existing CAMARA APIs,

• a service API which include a wide range of operations, and a resource hierarchy (i.e. `/{collection resource}/{resource ID})
• a subscriptions API

2. these APIs to be updated to align with Commonalities & ICM. This may not necessarily follow the Milestone cadence of meta-release APIs.

3. both the repository name and the API(s) names to clearly indicate that they are purely for CAMARA internal testing.

4. The APIs will not be included in any meta-release (also I don't think there's a need to make any releases of this repository, but would be interested to hear other views).

5. the info block will include section headings and template text from Commonalities and ICM. This will allow testing of workflows to generate PRs that update these when Commonalities & ICM templates change

6. otherwise the 'info' section should also indicate the API is purely for CAMARA internal testing

Any other considerations?

Quality on Demand seems a be a good API family to base the repository on, WDYT?

[hdamker]

Quality on Demand seems a be a good API family to base the repository on, WDYT?

QualityOnDemand has no explicit subscriptions API.

To fulfill both the criteria

• a service API which include a wide range of operations, and a resource hierarchy (i.e. `/{collection resource}/{resource ID})
• a subscriptions API

we might need to mix from two different repositories. The APIs with subscription APIs are mostly quite simple (one or two GET respective POST operations with verbs), while the ones with CRUD and resourceIDs don't have explicit subscription APIs.

[hdamker]

@Kevsy To test the automated roll-out of centralized linting I've created https://github.com/camaraproject/test-repo-w-linting and https://github.com/camaraproject/test-repo-wo-linting. After the tests for the linting deployment are done we can rename the repositories and use for the purpose above.

Currently both repositories contain two minimal "test-service" APIs which have the minimal elements to be valid CAMARA APIs (at least according to the guidelines). One with long lines, the other with wrapped lines.

We can create further synthetic test data (e.g. with certain issues, so invalid data) and/or use existing CAMARA APIs and copy them into the repositories.

P.S.: we might need to remove the "sandbox-api-repository" topic to avoid that they are showing up in reports.

[Kevsy]

Looks good @hdamker!

[hdamker]

For the current implementation of the new release workflow I will create test repositories within my account hdamker, as this is more flexible and less noisy for the camaraproject organization. At some point we can continue with TestRepositories in camaraproject, if there is a clearer picture what is helpful.