👍🎉 First off, thanks for taking the time to contribute! 🎉👍
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.
The current goal of the CAFprovider is to support the CAF landing zones but can also be used to standardize the naming convention of your projects. It is important to keep in mind that many of the design decisions on the provider have been made to accommodate the needs of CAF.
To contribute to this project you are required to have at least go 1.13 installed in your system
Please, find below the steps that should be followed to contribute:
-
Check if the resource has been implemented already
You can find a list of resources implemented in the README.md#resource-status under the resource status section.
-
Create an issue for the missing resource
If there is no issue created already for the implementation of this resource you should create an issue requesting the implementation of the resource.
-
Check the requirements for your resource Name
You can check the requirements for your resource name in the docs or by checking the error message returned when trying to create the resource on Azure with an invalid name. Slug value can also be checked in the CAF docs.
-
Choose the slug for the resource
Every resource in CAF does have a slug that associate with this resource this is 2 to 5 letters that identify that resource, for example, the slug for a
key vault
iskv
for a storage accountst
What is important here it is to try to keep this short but meaningful and avoid collision with existing ones. Don't worry about knowing all existing ones if you choose one that exists already the tests will fail. You can also check if the resource has a example abbreviation on this page: doc -
Modify the
resourceDefinition.json
You should now add your resource to the resource definitions in the just add another resource on the list. You can use the existing resources as a template for your resource implementation
-
Generate the definitions based on the
resourcedefinition.json
and testYou can run
make build
in case you have make installed in your system in case you don't you can run from the repository rootgo generate
followed bygo fmt ./...
and thengo test ./...
-
Update the README.MD with coverage
For quick reference, update the README.md#resource-status at the root of the provider to mention the coverage you just added:
|azurerm_api_management_custom_domain | ✔ |
-
Commit and submit PR
Now you should commit, remembering to put a meaningful commit message. After that, you should make pull request remembering to link in the PR the issue that it is solving.
Once you have all the information and have created an issue if one doesn't exist yet you can start to fill up the resource in the resourceDefinition.json
Each resource in the resourceDefinitions.json
follow the following schema:
{
"name": "azurerm_snapshots", //Azurerm name of the resource
"min_length": 1, // Minumum number of chars that this resource requires
"max_length": 80, // Maximum number of chars that this resource can have
"validation_regex": "\"^[a-zA-Z0-9][a-zA-Z0-9-._]{0,78}[a-zA-Z0-9_]$\"", // A regex expression that will match only a valid resource name
"scope": "parent", // Where this name must be unique. global means that only one resource with this name it is allowed in azure. parent means that only one resource of this name based in the parent resource. Resource group means only one resource with this name per resource group.
"slug": "snap", // This are the letters that identify the resource type
"dashes": true, // if this resource allows you to use dashes '-'
"lowercase": false, // if this resource will ONLY allow lowercase
"regex": "\"[^0-9A-Za-z_.-]\"" // This is the 'cleaning' regex anything that is matched by this regex will be removed from the resource name that is why you normally use the negation of all the allowed chars in this regex.
}
This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.
When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.