{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":674195763,"defaultBranch":"master","name":"witboost-terraform-scaffold","ownerLogin":"agile-lab-dev","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2023-08-03T11:07:05.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/22298838?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1702617966.0","currentOid":""},"activityList":{"items":[{"before":"c650ab403e855065b96276dd054ae0b47349f7fb","after":"6303f3dfc2ecf5d07bf6cc172d2b3a0968354fb8","ref":"refs/heads/master","pushedAt":"2024-04-26T16:31:42.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"nicolobidotti","name":null,"path":"/nicolobidotti","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/21340400?s=80&v=4"},"commit":{"message":"[WIT-2108] Add principal mapping for data product owner and dev group\n\n# New features and improvements\n\nAdded `Principal mapping` for `Data Product Owner` and `Dev Group` while provisioning\n\n# Breaking changes\n\nIn every module a new mandatory terraform variable definition is needed:\n```terraform\nvariable \"ownerPrincipals\" {\n  type        = string\n  description = \"The identities that own the Data Product\"\n  default = \"\"\n}\n```\n\n# Bug fixes\n\n- Fixed containerPort in `helm/templates/deployment.yaml`\n- Fixed module path for validation operation\n\n# Related issue\n\nCloses WIT-2108\n\n# Definition of Done for Feature/Hotfixes\n\n## All Developments\n\n- [x] Feature was implemented as per the requirements\n- [x] If some code parts are complex they must be commented with code documentation\n- [x] CI/CD is successful\n- [x] Code coverage is not reduced, any new code is covered\n- [x] E2E/integration tests are successful (whether run locally or in CI/CD)\n- [x] If dependencies were changed, be sure that they will not impact the project, that their license is compatible, and that they introduce no vulnerabilities\n- [x] Documentation have been updated\n  * Documentation has been updated with explanation of the new feature if it is user-facing (eg component now has additional setting) or it impacts him in some other way (eg optional field that becomes mandatory)\n  * If it is a breaking change, we have documented it as such in the MR description in a \"Breaking Changes\" section\n- [x] Check that you are not affecting any existing environments with these changes, especially the Sandbox/Playground. This means that merging it to master and deploying it to these environments will not break them and **no manual operations that are not reported in the documentation will be needed**\n- [x] Check that nothing is out of order and nothing problematic is included in the changes (sensitive information, credentials, customer information or other intellectual property) as they could end up being public (we have Open Source SP already published and automatically mirrored)\n- [x] Security, Authentication and Authorization have been considered. No SQL injection, tokens handling, RBAC integration. Common security vulnerabilities identified and resolved\n\n## API Development\n\n- [x] Semantic of API has been checked, it is comprehensible, meaningful, with no redundant information and user oriented\n- [x] Meaningful unit and integration tests are present\n- [x] API Parameters are checked and errors are handled\n- [x] Returned errors are meaningful to the user\n- [x] API contract has been defined and documented. Documentation means explaining the meaning of all fields and including at least one example\n- [x] Exceptions and errors are handled, without letting the underlying framework to respond with a generic Internal Server Error\n- [x] API Performance has been assessed and is good for real world use cases. Database accesses have been optimized.\n- [x] API is logging in compliance with audit standards, presence of sensitive information for GDPR has been assessed and removed or managed in case is needed\n\n## DB Development\n\n- [x] The database schema is designed to accurately represent the data model and meet the requirements\n- [x] Tables, relationships, and constraints (e.g. primary keys, foreign keys, unique constraints) are defined appropriately and following a common convention\n- [x] Normalization principles are applied to eliminate data redundancy and ensure data integrity\n- [x] Schema semantic is meaningful\n- [x] Fields naming are following naming convention ( Ex. camelCase or snake_case)\n- [x] No fields with mixed behaviors and meaning. If a field is representing an enum, enum values are strongly mutually exclusive\n- [x] Data Types have been reviewed and they are a good fit for each field\n- [x] Indexes are defined to optimize query performance for frequently accessed data, paying attention to do not affect too much write path and the overall complexity\n- [x] Sensitive data is stored securely, encrypted if required, and access is restricted to authorized users\n- [x] Backup and restore procedures have been updated to introduce new or changed tables\n- [x] Migration scripts to upgrade and downgrade the database have been implemented and tested","shortMessageHtmlLink":"[WIT-2108] Add principal mapping for data product owner and dev group"}},{"before":"824da29a4035aed83d2af7f330ccf946c91c36ae","after":"c650ab403e855065b96276dd054ae0b47349f7fb","ref":"refs/heads/master","pushedAt":"2024-04-17T14:11:51.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"nicolobidotti","name":null,"path":"/nicolobidotti","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/21340400?s=80&v=4"},"commit":{"message":"[WIT-2000] Prevent tf destroy if the resource is a storage\n\n# New features and improvements\n\nThis MR honours the `removeData` flag. When set to false, storage areas are not destroyed, i.e. the unprovision is skipped.\n\n# Definition of Done for Feature/Hotfixes\n\n## All Developments\n\n- [x] Feature was implemented as per the requirements\n- [x] If some code parts are complex they must be commented with code documentation\n- [x] CI/CD is successful\n- [ ] Code coverage is not reduced, any new code is covered\n- [x] E2E/integration tests are successful (whether run locally or in CI/CD)\n- [x] If dependencies were changed, be sure that they will not impact the project, that their license is compatible, and that they introduce no vulnerabilities\n- [x] Documentation have been updated\n  * Documentation has been updated with explanation of the new feature if it is user-facing (eg component now has additional setting) or it impacts him in some other way (eg optional field that becomes mandatory)\n  * If it is a breaking change, we have documented it as such in the MR description in a \"Breaking Changes\" section\n- [x] Check that you are not affecting any existing environments with these changes, especially the Sandbox/Playground. This means that merging it to master and deploying it to these environments will not break them and **no manual operations that are not reported in the documentation will be needed**\n- [x] Check that nothing is out of order and nothing problematic is included in the changes (sensitive information, credentials, customer information or other intellectual property) as they could end up being public (we have Open Source SP already published and automatically mirrored)\n- [x] Security, Authentication and Authorization have been considered. No SQL injection, tokens handling, RBAC integration. Common security vulnerabilities identified and resolved\n\n## API Development\n\n- [ ] Semantic of API has been checked, it is comprehensible, meaningful, with no redundant information and user oriented\n- [ ] Meaningful unit and integration tests are present\n- [ ] API Parameters are checked and errors are handled\n- [ ] Returned errors are meaningful to the user\n- [ ] API contract has been defined and documented. Documentation means explaining the meaning of all fields and including at least one example\n- [ ] Exceptions and errors are handled, without letting the underlying framework to respond with a generic Internal Server Error\n- [ ] API Performance has been assessed and is good for real world use cases. Database accesses have been optimized.\n- [ ] API is logging in compliance with audit standards, presence of sensitive information for GDPR has been assessed and removed or managed in case is needed\n\n## DB Development\n\n- [ ] The database schema is designed to accurately represent the data model and meet the requirements\n- [ ] Tables, relationships, and constraints (e.g. primary keys, foreign keys, unique constraints) are defined appropriately and following a common convention\n- [ ] Normalization principles are applied to eliminate data redundancy and ensure data integrity\n- [ ] Schema semantic is meaningful\n- [ ] Fields naming are following naming convention ( Ex. camelCase or snake_case)\n- [ ] No fields with mixed behaviors and meaning. If a field is representing an enum, enum values are strongly mutually exclusive\n- [ ] Data Types have been reviewed and they are a good fit for each field\n- [ ] Indexes are defined to optimize query performance for frequently accessed data, paying attention to do not affect too much write path and the overall complexity\n- [ ] Sensitive data is stored securely, encrypted if required, and access is restricted to authorized users\n- [ ] Backup and restore procedures have been updated to introduce new or changed tables\n- [ ] Migration scripts to upgrade and downgrade the database have been implemented and tested\n\nCloses WIT-2000","shortMessageHtmlLink":"[WIT-2000] Prevent tf destroy if the resource is a storage"}},{"before":"470f71c67514d0ba1cbed576b9d30b61abbe182f","after":"824da29a4035aed83d2af7f330ccf946c91c36ae","ref":"refs/heads/master","pushedAt":"2024-04-15T08:59:17.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"nicolobidotti","name":null,"path":"/nicolobidotti","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/21340400?s=80&v=4"},"commit":{"message":"[WIT-2009] Implement principals mapping from Witboost identities to Azure identities\n\n# New features and improvements\n\n- Implemented Azure Principal Mapping plugin\n- Updated logos\n\n# Related issue\n\nCloses WIT-2009\n\n# Definition of Done for Feature/Hotfixes\n\n## All Developments\n\n- [x] Feature was implemented as per the requirements\n- [x] If some code parts are complex they must be commented with code documentation\n- [x] CI/CD is successful\n- [x] Code coverage is not reduced, any new code is covered\n- [x] E2E/integration tests are successful (whether run locally or in CI/CD)\n- [x] If dependencies were changed, be sure that they will not impact the project, that their license is compatible, and that they introduce no vulnerabilities\n- [x] Documentation have been updated\n  * Documentation has been updated with explanation of the new feature if it is user-facing (eg component now has additional setting) or it impacts him in some other way (eg optional field that becomes mandatory)\n  * If it is a breaking change, we have documented it as such in the MR description in a \"Breaking Changes\" section\n- [x] Check that you are not affecting any existing environments with these changes, especially the Sandbox/Playground. This means that merging it to master and deploying it to these environments will not break them and **no manual operations that are not reported in the documentation will be needed**\n- x] Check that nothing is out of order and nothing problematic is included in the changes (sensitive information, credentials, customer information or other intellectual property) as they could end up being public (we have Open Source SP already published and automatically mirrored)\n- [x] Security, Authentication and Authorization have been considered. No SQL injection, tokens handling, RBAC integration. Common security vulnerabilities identified and resolved\n\n## API Development\n\n- [x] Semantic of API has been checked, it is comprehensible, meaningful, with no redundant information and user oriented\n- [x] Meaningful unit and integration tests are present\n- [x] API Parameters are checked and errors are handled\n- [x] Returned errors are meaningful to the user\n- [x] API contract has been defined and documented. Documentation means explaining the meaning of all fields and including at least one example\n- [x] Exceptions and errors are handled, without letting the underlying framework to respond with a generic Internal Server Error\n- [x] API Performance has been assessed and is good for real world use cases. Database accesses have been optimized.\n- [x] API is logging in compliance with audit standards, presence of sensitive information for GDPR has been assessed and removed or managed in case is needed\n\n## DB Development\n\n- [x] The database schema is designed to accurately represent the data model and meet the requirements\n- [x] Tables, relationships, and constraints (e.g. primary keys, foreign keys, unique constraints) are defined appropriately and following a common convention\n- [x] Normalization principles are applied to eliminate data redundancy and ensure data integrity\n- [x] Schema semantic is meaningful\n- [x] Fields naming are following naming convention ( Ex. camelCase or snake_case)\n- [x] No fields with mixed behaviors and meaning. If a field is representing an enum, enum values are strongly mutually exclusive\n- [x] Data Types have been reviewed and they are a good fit for each field\n- [x] Indexes are defined to optimize query performance for frequently accessed data, paying attention to do not affect too much write path and the overall complexity\n- [x] Sensitive data is stored securely, encrypted if required, and access is restricted to authorized users\n- [x] Backup and restore procedures have been updated to introduce new or changed tables\n- [x] Migration scripts to upgrade and downgrade the database have been implemented and tested","shortMessageHtmlLink":"[WIT-2009] Implement principals mapping from Witboost identities to A…"}},{"before":"0eebadbc3aaf85a50ceab4101cd824809b420980","after":"470f71c67514d0ba1cbed576b9d30b61abbe182f","ref":"refs/heads/master","pushedAt":"2024-04-03T09:38:47.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"nicolobidotti","name":null,"path":"/nicolobidotti","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/21340400?s=80&v=4"},"commit":{"message":"[WIT-1900] Add Azure Support\n\n# New features and improvements\n\n- Added Azure CLI in Docker image\n- Upgraded Terraform to version `1.7.5`\n- Upgraded Docker base image to `eclipse-temurin:11.0.22_7-jre-alpine`\n- Added ability to define extra volumes and extra volume mounts\n- Removed init-container. An umbrella chart will be used to deploy use cases along with this SP\n\n# Bug fixes\n\n- Fixed service port\n\n# Related issue\n\nCloses WIT-1900\n\n# Definition of Done for Feature/Hotfixes\n\n## All Developments\n\n- [x] Feature was implemented as per the requirements\n- [x] If some code parts are complex they must be commented with code documentation\n- [x] CI/CD is successful\n- [x] Code coverage is not reduced, any new code is covered\n- [x] E2E/integration tests are successful (whether run locally or in CI/CD)\n- [x] If dependencies were changed, be sure that they will not impact the project, that their license is compatible, and that they introduce no vulnerabilities\n- [x] Documentation have been updated\n  * Documentation has been updated with explanation of the new feature if it is user-facing (eg component now has additional setting) or it impacts him in some other way (eg optional field that becomes mandatory)\n  * If it is a breaking change, we have documented it as such in the MR description in a \"Breaking Changes\" section\n- [x] Check that you are not affecting any existing environments with these changes, especially the Sandbox/Playground. This means that merging it to master and deploying it to these environments will not break them and **no manual operations that are not reported in the documentation will be needed**\n- [x] Check that nothing is out of order and nothing problematic is included in the changes (sensitive information, credentials, customer information or other intellectual property) as they could end up being public (we have Open Source SP already published and automatically mirrored)\n- [x] Security, Authentication and Authorization have been considered. No SQL injection, tokens handling, RBAC integration. Common security vulnerabilities identified and resolved\n\n## API Development\n\n- [x] Semantic of API has been checked, it is comprehensible, meaningful, with no redundant information and user oriented\n- [x] Meaningful unit and integration tests are present\n- [x] API Parameters are checked and errors are handled\n- [x] Returned errors are meaningful to the user\n- [x] API contract has been defined and documented. Documentation means explaining the meaning of all fields and including at least one example\n- [x] Exceptions and errors are handled, without letting the underlying framework to respond with a generic Internal Server Error\n- [x] API Performance has been assessed and is good for real world use cases. Database accesses have been optimized.\n- [x] API is logging in compliance with audit standards, presence of sensitive information for GDPR has been assessed and removed or managed in case is needed\n\n## DB Development\n\n- [x] The database schema is designed to accurately represent the data model and meet the requirements\n- [x] Tables, relationships, and constraints (e.g. primary keys, foreign keys, unique constraints) are defined appropriately and following a common convention\n- [x] Normalization principles are applied to eliminate data redundancy and ensure data integrity\n- [x] Schema semantic is meaningful\n- [x] Fields naming are following naming convention ( Ex. camelCase or snake_case)\n- [x] No fields with mixed behaviors and meaning. If a field is representing an enum, enum values are strongly mutually exclusive\n- [x] Data Types have been reviewed and they are a good fit for each field\n- [x] Indexes are defined to optimize query performance for frequently accessed data, paying attention to do not affect too much write path and the overall complexity\n- [x] Sensitive data is stored securely, encrypted if required, and access is restricted to authorized users\n- [x] Backup and restore procedures have been updated to introduce new or changed tables\n- [x] Migration scripts to upgrade and downgrade the database have been implemented and tested","shortMessageHtmlLink":"[WIT-1900] Add Azure Support"}},{"before":"3708e0826bd1dc5fb4dd0ce7686198700441e04f","after":"d12fe7aacfa5e4e2ffbd702a8c07bc98eb813446","ref":"refs/heads/renovate/configure","pushedAt":"2023-12-15T05:25:54.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"renovate[bot]","name":null,"path":"/apps/renovate","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/2740?s=80&v=4"},"commit":{"message":"Add renovate.json","shortMessageHtmlLink":"Add renovate.json"}},{"before":"7d66be5e5767008de3b71e9b43dd4c661936b0bd","after":"0eebadbc3aaf85a50ceab4101cd824809b420980","ref":"refs/heads/master","pushedAt":"2023-11-22T16:51:03.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"nicolobidotti","name":null,"path":"/nicolobidotti","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/21340400?s=80&v=4"},"commit":{"message":"Resolve WIT-209 \"Terraform sp validation of descriptor contents with terraform validate\"\n\n# New features and improvements\n\nThis MR implements the `/v1/validate` endpoint.\n\nUnder the hood, we have to discriminate between the main module and the acl module.\n\nFor the former, a `terraform plan` happens. This allows a complete validation of the descriptor, but also of the configuration. For instance, a `terraform validate` would have left out the validation of `backendConfig` configuration, because the validate doesn't require the terraform state.\n\nFor the latter, a `terraform validate` happens. The reason why I had to fallback to this much trivial kind of validation (e.g. syntax only) is that at the time of validation we are missing the principals variables.\n\nThis MR doesn't remove the old DescriptorValidation flow, as it will be possibly be used by [WIT-693](https://witboost.atlassian.net/browse/WIT-693).\n\n# Bug fixes\n\nA bug in the `terraform/src/main/scala/it/agilelab/provisioners/terraform/TerraformResult.scala` was preventing the correct parsing of outputs, thus resulting in the returning of a generic \\`Details about the errors are not available. Contact the Platform team for assistance!\\`.\n\nThis was not correctly spotted in unit tests, as they were simply checking the presence of errors, without digging into the error message itself.\n\n# Definition of Done for Feature/Hotfixes\n\n## All Developments\n\n* [x] Feature was implemented as per the requirements\n* [x] If some code parts are complex they must be commented with code documentation\n* [x] CI/CD is successful\n* [x] Code coverage is not reduced, any new code is covered\n* [x] E2E/integration tests are successful (whether run locally or in CI/CD)\n* [x] If dependencies were changed, be sure that they will not impact the project, that their license is compatible, and that they introduce no vulnerabilities\n* [x] Documentation have been updated\n  * Documentation has been updated with explanation of the new feature if it is user-facing (eg component now has additional setting) or it impacts him in some other way (eg optional field that becomes mandatory)\n  * If it is a breaking change, we have documented it as such in the MR description in a \"Breaking Changes\" section\n* [x] Check that you are not affecting any existing environments with these changes, especially the Sandbox/Playground. This means that merging it to master and deploying it to these environments will not break them and **no manual operations that are not reported in the documentation will be needed**\n* [x] Check that nothing is out of order and nothing problematic is included in the changes (sensitive information, credentials, customer information or other intellectual property) as they could end up being public (we have Open Source SP already published and automatically mirrored)\n* [x] Security, Authentication and Authorization have been considered. No SQL injection, tokens handling, RBAC integration. Common security vulnerabilities identified and resolved\n\n## API Development\n\n* [ ] Semantic of API has been checked, it is comprehensible, meaningful, with no redundant information and user oriented\n* [ ] Meaningful unit and integration tests are present\n* [ ] API Parameters are checked and errors are handled\n* [ ] Returned errors are meaningful to the user\n* [ ] API contract has been defined and documented. Documentation means explaining the meaning of all fields and including at least one example\n* [ ] Exceptions and errors are handled, without letting the underlying framework to respond with a generic Internal Server Error\n* [ ] API Performance has been assessed and is good for real world use cases. Database accesses have been optimized.\n* [ ] API is logging in compliance with audit standards, presence of sensitive information for GDPR has been assessed and removed or managed in case is needed\n\n## DB Development\n\n* [ ] The database schema is designed to accurately represent the data model and meet the requirements\n* [ ] Tables, relationships, and constraints (e.g. primary keys, foreign keys, unique constraints) are defined appropriately and following a common convention\n* [ ] Normalization principles are applied to eliminate data redundancy and ensure data integrity\n* [ ] Schema semantic is meaningful\n* [ ] Fields naming are following naming convention ( Ex. camelCase or snake_case)\n* [ ] No fields with mixed behaviors and meaning. If a field is representing an enum, enum values are strongly mutually exclusive\n* [ ] Data Types have been reviewed and they are a good fit for each field\n* [ ] Indexes are defined to optimize query performance for frequently accessed data, paying attention to do not affect too much write path and the overall complexity\n* [ ] Sensitive data is stored securely, encrypted if required, and access is restricted to authorized users\n* [ ] Backup and restore procedures have been updated to introduce new or changed tables\n* [ ] Migration scripts to upgrade and downgrade the database have been implemented and tested\n\nCloses WIT-209","shortMessageHtmlLink":"Resolve WIT-209 \"Terraform sp validation of descriptor contents with …"}},{"before":"5446391df1e7350ed94fd518740057277c747178","after":"7d66be5e5767008de3b71e9b43dd4c661936b0bd","ref":"refs/heads/master","pushedAt":"2023-11-03T09:09:17.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"nicolobidotti","name":null,"path":"/nicolobidotti","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/21340400?s=80&v=4"},"commit":{"message":"Resolve WIT-564 \"Terraform sp doesn t manage multiple state file\"\n\n# Bug fixes\n\nThis MR allows the management of multiple state files.\n\n**Flow change**\n\nWhenever a new request arrives\n\n* a new temporary folder (context) is created\n* the terraform configuration is copied into it\n* the `init` operation is performed\n\nIn this way we're can manage multiple state and we handle concurrency problems.\n\n**Backend configs**\n\nWe now provide a way of specifying backend configs, with the usual JsonPath approach. In this way, it will be possible to dynamically specify the state key.\n\n# Definition of Done for Feature/Hotfixes\n\n## All Developments\n\n* [x] Feature was implemented as per the requirements\n* [x] If some code parts are complex they must be commented with code documentation\n* [x] CI/CD is successful\n* [x] Code coverage is not reduced, any new code is covered\n* [x] E2E/integration tests are successful (whether run locally or in CI/CD)\n* [x] If dependencies were changed, be sure that they will not impact the project, that their license is compatible, and that they introduce no vulnerabilities\n* [x] Documentation have been updated\n  * Documentation has been updated with explanation of the new feature if it is user-facing (eg component now has additional setting) or it impacts him in some other way (eg optional field that becomes mandatory)\n  * If it is a breaking change, we have documented it as such in the MR description in a \"Breaking Changes\" section\n* [x] Check that you are not affecting any existing environments with these changes, especially the Sandbox/Playground. This means that merging it to master and deploying it to these environments will not break them and **no manual operations that are not reported in the documentation will be needed**\n* [x] Check that nothing is out of order and nothing problematic is included in the changes (sensitive information, credentials, customer information or other intellectual property) as they could end up being public (we have Open Source SP already published and automatically mirrored)\n* [x] Security, Authentication and Authorization have been considered. No SQL injection, tokens handling, RBAC integration. Common security vulnerabilities identified and resolved\n\n## API Development\n\n* [ ] Semantic of API has been checked, it is comprehensible, meaningful, with no redundant information and user oriented\n* [ ] Meaningful unit and integration tests are present\n* [ ] API Parameters are checked and errors are handled\n* [ ] Returned errors are meaningful to the user\n* [ ] API contract has been defined and documented. Documentation means explaining the meaning of all fields and including at least one example\n* [ ] Exceptions and errors are handled, without letting the underlying framework to respond with a generic Internal Server Error\n* [ ] API Performance has been assessed and is good for real world use cases. Database accesses have been optimized.\n* [ ] API is logging in compliance with audit standards, presence of sensitive information for GDPR has been assessed and removed or managed in case is needed\n\n## DB Development\n\n* [ ] The database schema is designed to accurately represent the data model and meet the requirements\n* [ ] Tables, relationships, and constraints (e.g. primary keys, foreign keys, unique constraints) are defined appropriately and following a common convention\n* [ ] Normalization principles are applied to eliminate data redundancy and ensure data integrity\n* [ ] Schema semantic is meaningful\n* [ ] Fields naming are following naming convention ( Ex. camelCase or snake_case)\n* [ ] No fields with mixed behaviors and meaning. If a field is representing an enum, enum values are strongly mutually exclusive\n* [ ] Data Types have been reviewed and they are a good fit for each field\n* [ ] Indexes are defined to optimize query performance for frequently accessed data, paying attention to do not affect too much write path and the overall complexity\n* [ ] Sensitive data is stored securely, encrypted if required, and access is restricted to authorized users\n* [ ] Backup and restore procedures have been updated to introduce new or changed tables\n* [ ] Migration scripts to upgrade and downgrade the database have been implemented and tested\n\nCloses WIT-564","shortMessageHtmlLink":"Resolve WIT-564 \"Terraform sp doesn t manage multiple state file\""}},{"before":"de6675052dc038b8779cef694e12d9d5ebfee3d9","after":"5446391df1e7350ed94fd518740057277c747178","ref":"refs/heads/master","pushedAt":"2023-10-30T17:04:35.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"nicolobidotti","name":null,"path":"/nicolobidotti","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/21340400?s=80&v=4"},"commit":{"message":"[WIT-223] Terraform SP Helm chart\n\n# New features and improvements\n\nThis MR introduces the helm chart needed to deploy the Terraform SP on a k8s cluster.\n\n### Config management\n\n* application.conf and logback.xml can be overridden via values.yaml\n* Terraform configurations are trickier. Since we cannot inject them at installation time (because helm doesn't allow to create configmap locations external to the chart), the configmap containing the configurations must be created before installing the helm. That is, if the helm needs the configmap as prereq. This is well documented in the helm README.md.\n\n# Bug fixes\n\nThis MR fixes the version used to deploy the docker image. It was \"master\" by default, now it is using versioning\n\n# Definition of Done for Feature/Hotfixes\n\n## All Developments\n\n* [x] Feature was implemented as per the requirements\n* [x] If some code parts are complex they must be commented with code documentation\n* [x] CI/CD is successful\n* [x] Code coverage is not reduced, any new code is covered\n* [x] E2E/integration tests are successful (whether run locally or in CI/CD)\n* [x] If dependencies were changed, be sure that they will not impact the project, that their license is compatible, and that they introduce no vulnerabilities\n* [x] Documentation have been updated\n  * Documentation has been updated with explanation of the new feature if it is user-facing (eg component now has additional setting) or it impacts him in some other way (eg optional field that becomes mandatory)\n  * If it is a breaking change, we have documented it as such in the MR description in a \"Breaking Changes\" section\n* [x] Check that you are not affecting any existing environments with these changes, especially the Sandbox/Playground. This means that merging it to master and deploying it to these environments will not break them and **no manual operations that are not reported in the documentation will be needed**\n* [x] Check that nothing is out of order and nothing problematic is included in the changes (sensitive information, credentials, customer information or other intellectual property) as they could end up being public (we have Open Source SP already published and automatically mirrored)\n* [x] Security, Authentication and Authorization have been considered. No SQL injection, tokens handling, RBAC integration. Common security vulnerabilities identified and resolved\n\n## API Development\n\n* [ ] Semantic of API has been checked, it is comprehensible, meaningful, with no redundant information and user oriented\n* [ ] Meaningful unit and integration tests are present\n* [ ] API Parameters are checked and errors are handled\n* [ ] Returned errors are meaningful to the user\n* [ ] API contract has been defined and documented. Documentation means explaining the meaning of all fields and including at least one example\n* [ ] Exceptions and errors are handled, without letting the underlying framework to respond with a generic Internal Server Error\n* [ ] API Performance has been assessed and is good for real world use cases. Database accesses have been optimized.\n* [ ] API is logging in compliance with audit standards, presence of sensitive information for GDPR has been assessed and removed or managed in case is needed\n\n## DB Development\n\n* [ ] The database schema is designed to accurately represent the data model and meet the requirements\n* [ ] Tables, relationships, and constraints (e.g. primary keys, foreign keys, unique constraints) are defined appropriately and following a common convention\n* [ ] Normalization principles are applied to eliminate data redundancy and ensure data integrity\n* [ ] Schema semantic is meaningful\n* [ ] Fields naming are following naming convention ( Ex. camelCase or snake_case)\n* [ ] No fields with mixed behaviors and meaning. If a field is representing an enum, enum values are strongly mutually exclusive\n* [ ] Data Types have been reviewed and they are a good fit for each field\n* [ ] Indexes are defined to optimize query performance for frequently accessed data, paying attention to do not affect too much write path and the overall complexity\n* [ ] Sensitive data is stored securely, encrypted if required, and access is restricted to authorized users\n* [ ] Backup and restore procedures have been updated to introduce new or changed tables\n* [ ] Migration scripts to upgrade and downgrade the database have been implemented and tested\n\nCloses WIT-223","shortMessageHtmlLink":"[WIT-223] Terraform SP Helm chart"}},{"before":"090141c581338cd34161d2edde4d915708cd779d","after":"de6675052dc038b8779cef694e12d9d5ebfee3d9","ref":"refs/heads/master","pushedAt":"2023-10-16T15:44:48.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"nicolobidotti","name":null,"path":"/nicolobidotti","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/21340400?s=80&v=4"},"commit":{"message":"[WIT-224] Implement multi-module\n\n# New features and improvements\n\nMulti-module support\n\n# Breaking changes\n\nConfiguration section `datameshProvisioner.terraform` changed to support multiple modules.\n\nNew structure is:\n```\ndatameshProvisioner {\n  ...\n  terraform {\n    moduleId1 {\n      repositoryPath: \"path-for-moduleId1\"\n      descriptorToVariablesMapping: {}\n      principalMappingPlugin {\n        pluginClass: \"\"\n      }\n    }\n    moduleId2 {\n      repositoryPath: \"path-for-moduleId2\"\n      descriptorToVariablesMapping: {}\n      principalMappingPlugin {\n        pluginClass: \"\"\n      }\n    }\n  }\n}\n```\nSee the updated documentation for the details.\n\n# Related issue\n\nCloses WIT-224","shortMessageHtmlLink":"[WIT-224] Implement multi-module"}},{"before":"e2c8c35c0cea0fa7408466deb4dae2487de412a2","after":"090141c581338cd34161d2edde4d915708cd779d","ref":"refs/heads/master","pushedAt":"2023-10-10T15:25:19.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"nicolobidotti","name":null,"path":"/nicolobidotti","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/21340400?s=80&v=4"},"commit":{"message":"Resolve WIT-307 \"Update hld with updateacl feature\"\n\n# New features and improvements\n\nThis MR enriches the HLD with the updateAcl mechanism.\n\n# Related issue\n\nCloses WIT-307\n\n# Definition of Done for Feature/Hotfixes\n\n## All Developments\n\n* [x] Feature was implemented as per the requirements\n* [x] If some code parts are complex they must be commented with code documentation\n* [x] CI/CD is successful\n* [x] Code coverage is not reduced, any new code is covered\n* [x] E2E/integration tests are successful (whether run locally or in CI/CD)\n* [x] If dependencies were changed, be sure that they will not impact the project, that their license is compatible, and that they introduce no vulnerabilities\n* [x] Documentation have been updated\n  * Documentation has been updated with explanation of the new feature if it is user-facing (eg component now has additional setting) or it impacts him in some other way (eg optional field that becomes mandatory)\n  * If it is a breaking change, we have documented it as such in the MR description in a \"Breaking Changes\" section\n* [x] Check that you are not affecting any existing environments with these changes, especially the Sandbox/Playground. This means that merging it to master and deploying it to these environments will not break them and **no manual operations that are not reported in the documentation will be needed**\n* [x] Check that nothing is out of order and nothing problematic is included in the changes (sensitive information, credentials, customer information or other intellectual property) as they could end up being public (we have Open Source SP already published and automatically mirrored)\n* [x] Security, Authentication and Authorization have been considered. No SQL injection, tokens handling, RBAC integration. Common security vulnerabilities identified and resolved\n\n## API Development\n\n* [x] Semantic of API has been checked, it is comprehensible, meaningful, with no redundant information and user oriented\n* [x] Meaningful unit and integration tests are present\n* [x] API Parameters are checked and errors are handled\n* [x] Returned errors are meaningful to the user\n* [x] API contract has been defined and documented. Documentation means explaining the meaning of all fields and including at least one example\n* [x] Exceptions and errors are handled, without letting the underlying framework to respond with a generic Internal Server Error\n* [x] API Performance has been assessed and is good for real world use cases. Database accesses have been optimized.\n* [x] API is logging in compliance with audit standards, presence of sensitive information for GDPR has been assessed and removed or managed in case is needed\n\n## DB Development\n\n* [x] The database schema is designed to accurately represent the data model and meet the requirements\n* [x] Tables, relationships, and constraints (e.g. primary keys, foreign keys, unique constraints) are defined appropriately and following a common convention\n* [x] Normalization principles are applied to eliminate data redundancy and ensure data integrity\n* [x] Schema semantic is meaningful\n* [x] Fields naming are following naming convention ( Ex. camelCase or snake_case)\n* [x] No fields with mixed behaviors and meaning. If a field is representing an enum, enum values are strongly mutually exclusive\n* [x] Data Types have been reviewed and they are a good fit for each field\n* [x] Indexes are defined to optimize query performance for frequently accessed data, paying attention to do not affect too much write path and the overall complexity\n* [x] Sensitive data is stored securely, encrypted if required, and access is restricted to authorized users\n* [x] Backup and restore procedures have been updated to introduce new or changed tables\n* [x] Migration scripts to upgrade and downgrade the database have been implemented and tested","shortMessageHtmlLink":"Resolve WIT-307 \"Update hld with updateacl feature\""}},{"before":"264ece6ce9f68cdc2b80ee18d0485f881565ae75","after":"e2c8c35c0cea0fa7408466deb4dae2487de412a2","ref":"refs/heads/master","pushedAt":"2023-10-10T10:08:35.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"nicolobidotti","name":null,"path":"/nicolobidotti","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/21340400?s=80&v=4"},"commit":{"message":"Resolve WIT-376 \"Revert info extraction from body params\"\n\n# Bug fixes\n\nThis MR fixes a bug introduced in WIT-156.\n\nThe `Info` block, which contains `publicInfo` and `privateInfo` objects, is contained in the `result` object, not in the `request`.\n\n**Request**\n\n```json\n{\"dataProduct\":{\"id\":\"urn:dmb:dp:finance:my-dp:0\",\"email\":\"carlo.ventrella@agilelab.it\",\"domain\":\"finance\",\"maturity\":null,\"useCaseTemplateId\":\"urn:dmb:utm:dataproduct-template:0.0.0\",\"tags\":[],\"description\":\"dp\",\"kind\":\"dataproduct\",\"infrastructureTemplateId\":\"urn:dmb:itm:dataproduct-provisioner:1\",\"ownerGroup\":\"carlo.ventrella_agilelab.it\",\"devGroup\":\"bigdata\",\"components\":[{\"name\":\"myS3Op\",\"useCaseTemplateId\":\"urn:dmb:utm:aws-s3-bucket-template:0.0.0\",\"fullyQualifiedName\":null,\"componentOwner\":\"agilelab\",\"description\":\"asd\",\"outputPortType\":\"S3\",\"dependsOn\":[],\"version\":\"0.0.0\",\"infrastructureTemplateId\":\"urn:dmb:itm:terraform-sp:0\",\"specific\":{\"bucketName\":\"mymagicbuckettf\"},\"kind\":\"outputport\",\"id\":\"urn:dmb:cmp:tf-s3-bucket\"}],\"dataProductOwnerDisplayName\":\"Carlo Ventrella\",\"billing\":{},\"domainId\":\"urn:dmb:dmn:finance\",\"version\":\"0.2.0-SNAPSHOT-2\",\"fullyQualifiedName\":\"my dp\",\"name\":\"my-dp\",\"specific\":{},\"dataProductOwner\":\"user:carlo.ventrella_agilelab.it\",\"environment\":\"development\",\"informationSLA\":null},\"componentIdToProvision\":\"urn:dmb:cmp:tf-s3-bucket\"}\n```\n\n**Result**\n\n```json\n{\"status\":\"COMPLETED\",\"result\":\"\",\"info\":{\"publicInfo\":{},\"privateInfo\":{\"outputs\":{\"comp_id\":{\"value\":\"/subscriptions/61eabe24-6c0f-40d4-bd5c-4a7f9026e819/resourceGroups/witboost/providers/Microsoft.Storage/storageAccounts/tfspecificprovisionertwo\"},\"comp_name\":{\"value\":\"tfspecificprovisionertwo\"}}}},\"logs\":null}\n```\n\n# Related issue\n\nCloses WIT-376\n\n# Definition of Done for Feature/Hotfixes\n\n## All Developments\n\n* [x] Feature was implemented as per the requirements\n* [x] If some code parts are complex they must be commented with code documentation\n* [x] CI/CD is successful\n* [x] Code coverage is not reduced, any new code is covered\n* [x] E2E/integration tests are successful (whether run locally or in CI/CD)\n* [x] If dependencies were changed, be sure that they will not impact the project, that their license is compatible, and that they introduce no vulnerabilities\n* [x] Documentation have been updated\n  * Documentation has been updated with explanation of the new feature if it is user-facing (eg component now has additional setting) or it impacts him in some other way (eg optional field that becomes mandatory)\n  * If it is a breaking change, we have documented it as such in the MR description in a \"Breaking Changes\" section\n* [x] Check that you are not affecting any existing environments with these changes, especially the Sandbox/Playground. This means that merging it to master and deploying it to these environments will not break them and **no manual operations that are not reported in the documentation will be needed**\n* [x] Check that nothing is out of order and nothing problematic is included in the changes (sensitive information, credentials, customer information or other intellectual property) as they could end up being public (we have Open Source SP already published and automatically mirrored)\n* [x] Security, Authentication and Authorization have been considered. No SQL injection, tokens handling, RBAC integration. Common security vulnerabilities identified and resolved\n\n## API Development\n\n* [x] Semantic of API has been checked, it is comprehensible, meaningful, with no redundant information and user oriented\n* [x] Meaningful unit and integration tests are present\n* [x] API Parameters are checked and errors are handled\n* [x] Returned errors are meaningful to the user\n* [x] API contract has been defined and documented. Documentation means explaining the meaning of all fields and including at least one example\n* [x] Exceptions and errors are handled, without letting the underlying framework to respond with a generic Internal Server Error\n* [x] API Performance has been assessed and is good for real world use cases. Database accesses have been optimized.\n* [x] API is logging in compliance with audit standards, presence of sensitive information for GDPR has been assessed and removed or managed in case is needed\n\n## DB Development\n\n* [x] The database schema is designed to accurately represent the data model and meet the requirements\n* [x] Tables, relationships, and constraints (e.g. primary keys, foreign keys, unique constraints) are defined appropriately and following a common convention\n* [x] Normalization principles are applied to eliminate data redundancy and ensure data integrity\n* [x] Schema semantic is meaningful\n* [x] Fields naming are following naming convention ( Ex. camelCase or snake_case)\n* [x] No fields with mixed behaviors and meaning. If a field is representing an enum, enum values are strongly mutually exclusive\n* [x] Data Types have been reviewed and they are a good fit for each field\n* [x] Indexes are defined to optimize query performance for frequently accessed data, paying attention to do not affect too much write path and the overall complexity\n* [x] Sensitive data is stored securely, encrypted if required, and access is restricted to authorized users\n* [x] Backup and restore procedures have been updated to introduce new or changed tables\n* [x] Migration scripts to upgrade and downgrade the database have been implemented and tested","shortMessageHtmlLink":"Resolve WIT-376 \"Revert info extraction from body params\""}},{"before":"35ba5db9c8f7be4cabf5739edbc1651243af2623","after":"264ece6ce9f68cdc2b80ee18d0485f881565ae75","ref":"refs/heads/master","pushedAt":"2023-10-04T15:46:10.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"nicolobidotti","name":null,"path":"/nicolobidotti","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/21340400?s=80&v=4"},"commit":{"message":"[WIT-156] Implement updateAcl logic\n\n# New features and improvements\n\nImplemented updateAcl feature\n\n# Related issue\n\nCloses WIT-156\n\n# Definition of Done for Feature/Hotfixes\n\n## All Developments\n\n- [X] Feature was implemented as per the requirements\n- [X] If some code parts are complex they must be commented with code documentation\n- [X] CI/CD is successful\n- [x] Code coverage is not reduced, any new code is covered\n- [X] E2E/integration tests are successful (whether run locally or in CI/CD)\n- [X] If dependencies were changed, be sure that they will not impact the project, that their license is compatible, and that they introduce no vulnerabilities\n- [X] Documentation have been updated\n  * Documentation has been updated with explanation of the new feature if it is user-facing (eg component now has additional setting) or it impacts him in some other way (eg optional field that becomes mandatory)\n  * If it is a breaking change, we have documented it as such in the MR description in a \"Breaking Changes\" section\n- [X] Check that you are not affecting any existing environments with these changes, especially the Sandbox/Playground. This means that merging it to master and deploying it to these environments will not break them and **no manual operations that are not reported in the documentation will be needed**\n- [X] Check that nothing is out of order and nothing problematic is included in the changes (sensitive information, credentials, customer information or other intellectual property) as they could end up being public (we have Open Source SP already published and automatically mirrored)\n- [X] Security, Authentication and Authorization have been considered. No SQL injection, tokens handling, RBAC integration. Common security vulnerabilities identified and resolved\n\n## API Development\n\n- [X] Semantic of API has been checked, it is comprehensible, meaningful, with no redundant information and user oriented\n- [X] Meaningful unit and integration tests are present\n- [X] API Parameters are checked and errors are handled\n- [X] Returned errors are meaningful to the user\n- [X] API contract has been defined and documented. Documentation means explaining the meaning of all fields and including at least one example\n- [X] Exceptions and errors are handled, without letting the underlying framework to respond with a generic Internal Server Error\n- [X] API Performance has been assessed and is good for real world use cases. Database accesses have been optimized.\n- [X] API is logging in compliance with audit standards, presence of sensitive information for GDPR has been assessed and removed or managed in case is needed\n\n## DB Development\n\n- [X] The database schema is designed to accurately represent the data model and meet the requirements\n- [X] Tables, relationships, and constraints (e.g. primary keys, foreign keys, unique constraints) are defined appropriately and following a common convention\n- [X] Normalization principles are applied to eliminate data redundancy and ensure data integrity\n- [X] Schema semantic is meaningful\n- [X] Fields naming are following naming convention ( Ex. camelCase or snake_case)\n- [X] No fields with mixed behaviors and meaning. If a field is representing an enum, enum values are strongly mutually exclusive\n- [X] Data Types have been reviewed and they are a good fit for each field\n- [X] Indexes are defined to optimize query performance for frequently accessed data, paying attention to do not affect too much write path and the overall complexity\n- [X] Sensitive data is stored securely, encrypted if required, and access is restricted to authorized users\n- [X] Backup and restore procedures have been updated to introduce new or changed tables\n- [X] Migration scripts to upgrade and downgrade the database have been implemented and tested","shortMessageHtmlLink":"[WIT-156] Implement updateAcl logic"}},{"before":"783226ecb7dc9232d08101ab04da0802a592d790","after":"35ba5db9c8f7be4cabf5739edbc1651243af2623","ref":"refs/heads/master","pushedAt":"2023-09-19T09:45:51.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"nicolobidotti","name":null,"path":"/nicolobidotti","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/21340400?s=80&v=4"},"commit":{"message":"Resolve WIT-159 \"Implement a principals mapping plugin\"","shortMessageHtmlLink":"Resolve WIT-159 \"Implement a principals mapping plugin\""}},{"before":null,"after":"3708e0826bd1dc5fb4dd0ce7686198700441e04f","ref":"refs/heads/renovate/configure","pushedAt":"2023-09-18T16:11:04.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"renovate[bot]","name":null,"path":"/apps/renovate","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/2740?s=80&v=4"},"commit":{"message":"Add renovate.json","shortMessageHtmlLink":"Add renovate.json"}},{"before":"b3e8f154bbd78f300b2e067816c08afdf714b287","after":"783226ecb7dc9232d08101ab04da0802a592d790","ref":"refs/heads/master","pushedAt":"2023-09-14T15:09:31.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"nicolobidotti","name":null,"path":"/nicolobidotti","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/21340400?s=80&v=4"},"commit":{"message":"Resolve WIT-155 \"Return tf outputs in provisioninfo\"","shortMessageHtmlLink":"Resolve WIT-155 \"Return tf outputs in provisioninfo\""}},{"before":"757babde9fa85de92c099460a7c646f2f3aa191c","after":"b3e8f154bbd78f300b2e067816c08afdf714b287","ref":"refs/heads/master","pushedAt":"2023-09-11T13:13:02.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"nicolobidotti","name":null,"path":"/nicolobidotti","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/21340400?s=80&v=4"},"commit":{"message":"[WIT-176] Multi-module HLD Design","shortMessageHtmlLink":"[WIT-176] Multi-module HLD Design"}},{"before":"54957fd26ded0965b166bc4b97c37745fa9a81b5","after":"757babde9fa85de92c099460a7c646f2f3aa191c","ref":"refs/heads/master","pushedAt":"2023-09-01T15:13:26.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"nicolobidotti","name":null,"path":"/nicolobidotti","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/21340400?s=80&v=4"},"commit":{"message":"[WIT-144] Porting to V2 API","shortMessageHtmlLink":"[WIT-144] Porting to V2 API"}},{"before":"2d6480f7068fad2823f34b9ce931a4245e828f38","after":"54957fd26ded0965b166bc4b97c37745fa9a81b5","ref":"refs/heads/master","pushedAt":"2023-08-29T10:20:16.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"nicolobidotti","name":null,"path":"/nicolobidotti","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/21340400?s=80&v=4"},"commit":{"message":"[#12] TfDependencies uses scala.reflect.io.File","shortMessageHtmlLink":"[#12] TfDependencies uses scala.reflect.io.File"}},{"before":"606d7b8ad9026440dc552adc365a44a62790654c","after":"2d6480f7068fad2823f34b9ce931a4245e828f38","ref":"refs/heads/master","pushedAt":"2023-08-07T06:47:49.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"nicolobidotti","name":null,"path":"/nicolobidotti","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/21340400?s=80&v=4"},"commit":{"message":"[#9] Stack trace is sent out in case of 500 errors","shortMessageHtmlLink":"[#9] Stack trace is sent out in case of 500 errors"}},{"before":"81957d95ed1bb50b0e95f687e2cdbb09f7d647a9","after":"606d7b8ad9026440dc552adc365a44a62790654c","ref":"refs/heads/master","pushedAt":"2023-08-03T17:02:58.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"nicolobidotti","name":null,"path":"/nicolobidotti","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/21340400?s=80&v=4"},"commit":{"message":"[#18] Starter Kit naming","shortMessageHtmlLink":"[#18] Starter Kit naming"}},{"before":null,"after":"81957d95ed1bb50b0e95f687e2cdbb09f7d647a9","ref":"refs/heads/master","pushedAt":"2023-08-03T11:09:15.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"nicolobidotti","name":null,"path":"/nicolobidotti","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/21340400?s=80&v=4"},"commit":{"message":"[#17] Documentation","shortMessageHtmlLink":"[#17] Documentation"}}],"hasNextPage":false,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEO1j9aQA","startCursor":null,"endCursor":null}},"title":"Activity · agile-lab-dev/witboost-terraform-scaffold"}