forked from Azure/azure-rest-api-specs
-
Notifications
You must be signed in to change notification settings - Fork 0
Workflow
Laurent Mazuel edited this page Apr 21, 2016
·
2 revisions
This document describes the workflow of the Azure SDKs.
This document is draft. Do not rely on it without having a discussion with the Azure SDK team.
When someone submit a PR on azure-rest-api, this triggers:
- Syntax checker of all the Swagger files
- SDK generation locally. This allows to test if the Swagger file is "compatible" with current Autorest version. This test only the files in the swagger_to_sdk.json file in each SDK repo. This does not consider the list of files effectively changed in the PR.
When the PR is merged:
- This creates a RestApi-master (master because it's where the branch is merged) branch on each SDK repository with the content of the generation. This generates only the files in the swagger_to_sdk.json file in each SDK repo. This does not consider the list of files effectively changed in the PR.
- Since this creates a new branch, this triggers Travis and the unittesting of the SDK. The Travis state is available in the initial (merged) PR as a comment.
- This creates a PR in the SDK repo from this branch.
- This asks a specific github user AutorestCI to have a fork of each SDK repo.
The current limitations are:
- Having the PR merged in rest-api to launch the SDK unitesting makes me uncomfortable.
- The current workflow makes all PR push in RestApi-master.
- The real content of the rest-api PR is not considered. We should be able (at least in step one) to generate the SDK for the files inside the PR only.
- We wants the Travis status of the SDK inside the initial PR (not a comment, the real status). This requires a way for the SDK to communicate back to the rest-api repo. A bot is the best option right now, since this solves the credentials issue.
If someone wants it's own fork of the rest-api AND the SDK repo. To be continued.