From fdf66df52721bab7bc97b3cf7a1264a54b19a8c8 Mon Sep 17 00:00:00 2001 From: Abdellah Date: Tue, 3 Mar 2026 15:37:43 +0100 Subject: [PATCH 1/4] update: deleting the review dates --- docs/CODEOWNERS | 1 + docs/backend/database.md | 1 - docs/backend/docker-usage.md | 5 ++--- docs/backend/handling-access-tokens.md | 1 - docs/frontend/accessibility.md | 2 -- docs/frontend/third-party-dependencies.md | 2 -- docs/general/github-copilot.md | 7 +++++++ docs/general/languages-and-frameworks.md | 2 -- docs/general/project-documentation.md | 1 - docs/general/readme-default.md | 2 -- docs/general/secure-coding.md | 2 -- docs/general/storing-source-code.md | 14 ++++++++------ docs/general/testing.md | 8 +++----- docs/general/third-party-dependencies.md | 2 -- docs/general/using-git.md | 1 - docs/intro.md | 2 +- 16 files changed, 22 insertions(+), 31 deletions(-) create mode 100644 docs/CODEOWNERS create mode 100644 docs/general/github-copilot.md diff --git a/docs/CODEOWNERS b/docs/CODEOWNERS new file mode 100644 index 0000000..ed93980 --- /dev/null +++ b/docs/CODEOWNERS @@ -0,0 +1 @@ +* @Amsterdam/enablement \ No newline at end of file diff --git a/docs/backend/database.md b/docs/backend/database.md index 984bd5c..ef3bc16 100644 --- a/docs/backend/database.md +++ b/docs/backend/database.md @@ -1,5 +1,4 @@ # Database -> This page was last reviewed on 27-08-2025. It needs to be reviewed again on 27-05-2026. The database is quite often at the core of our applications. It is used to store and query data. While this data will be structured most of the time, sometimes it is useful to be able to store diff --git a/docs/backend/docker-usage.md b/docs/backend/docker-usage.md index 2a3c099..02fe8e0 100644 --- a/docs/backend/docker-usage.md +++ b/docs/backend/docker-usage.md @@ -1,10 +1,9 @@ # Docker usage -> This page was last reviewed July 8th, 2025. It needs to be reviewed again on April 8th, 2026. ## What is the standard for Docker? Use Docker for containerization in the development, testing, and production of applications within the Municipality. Developers must use Dockerfiles that meet the minimum requirements outlined below. Dockerfiles are stored in the application repository in **GitHub**, while the compiled Docker images are stored in **Azure Container Registry (ACR)**. ## When and for whom is this standard applicable? -This guideline applies to all developers (front-end and back-end), IT administrators, and DevOps teams within the Municipality. It applies to all projects. Projects that started before September 2024 with a different configuration must be adapted to this standard. +This guideline applies to all developers (front-end and back-end), IT administrators, and DevOps teams within the Municipality. It applies to all projects. ## What is required when using Docker? @@ -12,7 +11,7 @@ This guideline applies to all developers (front-end and back-end), IT administra - [ ] **Base Image**: Use well-known and well-maintained base images and make sure that the version number is the latest, otherwise -2/-3 of the latest version. In addition, it is of high importance that the version number should **never** explicitly state `latest`. The most commonly used images are: Alpine, NGINX, Node.js, PHP, Postgres, Python and Ubuntu. - [ ] **Minimal Installations**: Limit the installation of additional packages to what is strictly necessary to keep the image lightweight and secure. - [ ] **Version Control**: Explicitly specify the versions of all dependencies to ensure consistency. -- **Docker Image Storage**: Dockerfiles must be stored in the application repository in **GitHub**. The compiled Docker images must be stored in **ACR**. Only in cases where an image is shared across multiple teams or other municipalities may **Docker Hub** be used. +- **Docker Image Storage**: Dockerfiles must be stored in the application repository in **GitHub**. The compiled Docker images must be stored in **ACR**. **Docker Hub** is to be used only in approved situations where an image needs to be shared between multiple teams or municipalities. ## Standard ADO Pipelines diff --git a/docs/backend/handling-access-tokens.md b/docs/backend/handling-access-tokens.md index 02de6ad..90c75f4 100644 --- a/docs/backend/handling-access-tokens.md +++ b/docs/backend/handling-access-tokens.md @@ -1,5 +1,4 @@ # Handling Access Tokens -> This page was last reviewed on 10-09-2025. It needs to be reviewed again on 10-06-2026. A common requirement for our applications is that we need to implement authentication. We typically do that by implementing OpenId Connect (OIDC) support. diff --git a/docs/frontend/accessibility.md b/docs/frontend/accessibility.md index ad416be..963165a 100644 --- a/docs/frontend/accessibility.md +++ b/docs/frontend/accessibility.md @@ -1,7 +1,5 @@ # Accessibility -> This page was last reviewed on 6 February 2025. It needs to be reviewed again on 6 November 2025. - ## What is the standard for accessibility? In accordance with the Digital Government Act, the municipality of Amsterdam is required to build all its websites and applications in compliance with the Web Content Accessibility Guidelines (WCAG) 2.1 at AA level. diff --git a/docs/frontend/third-party-dependencies.md b/docs/frontend/third-party-dependencies.md index a44efd4..96e3d30 100644 --- a/docs/frontend/third-party-dependencies.md +++ b/docs/frontend/third-party-dependencies.md @@ -1,7 +1,5 @@ # Third Party Dependencies -> This page was last reviewed on July 8th, 2025. It needs to be reviewed again on April 8th, 2026. - Guidelines for choosing a third party package can be found in the [general third party dependencies documentation page](../general/third-party-dependencies.md). ## How can you secure front-end third-party integrations? diff --git a/docs/general/github-copilot.md b/docs/general/github-copilot.md new file mode 100644 index 0000000..73ee806 --- /dev/null +++ b/docs/general/github-copilot.md @@ -0,0 +1,7 @@ +# GitHub Copilot Usage Rules + +This document provides the standard for using GitHub Copilot within our organization. It outlines the rules, guidelines, and best practices to ensure Copilot is used safely and responsibly, while maintaining software quality and compliance with our internal policies. By following these rules, developers can benefit from Copilot while reducing risks related to personal data, bias, and insufficient testing. + +Please note that this documentation is only visible to developers who have access to the Amsterdam organization in GitHub. + +For more details and the full documentation, please visit the official repository via the following link: [GitHub Copilot Usage Rules](https://github.com/Amsterdam/development-standards/tree/main/internal/github-copilot.md). diff --git a/docs/general/languages-and-frameworks.md b/docs/general/languages-and-frameworks.md index 78765b0..f9320f6 100644 --- a/docs/general/languages-and-frameworks.md +++ b/docs/general/languages-and-frameworks.md @@ -1,7 +1,5 @@ # Languages & Frameworks for Software Development -> This page was last reviewed on 10th April. It needs to be reviewed again on 10th January 2026. - ## What is the standard? ### Backend diff --git a/docs/general/project-documentation.md b/docs/general/project-documentation.md index a652479..7ffd441 100644 --- a/docs/general/project-documentation.md +++ b/docs/general/project-documentation.md @@ -1,5 +1,4 @@ # Documentation -> This page was last reviewed 13 February 2025. It needs to be reviewed again on 13 November 2025. ## What is the standard for documentation? Include documentation in your project that facilitates understanding, usage, and maintenance of your code. The documentation should promote usability and longevity of your project, and effective collaboration among your stakeholders. diff --git a/docs/general/readme-default.md b/docs/general/readme-default.md index 194cf50..fb7dd3d 100644 --- a/docs/general/readme-default.md +++ b/docs/general/readme-default.md @@ -1,7 +1,5 @@ # Readme files -> This page was last reviewed on February 3rd, 2025. It needs to be reviewed again on November 3rd, 2025. - ## What is the standard for a README for the city of Amsterdam? There must be a README.md file for every Github repository of the city of Amsterdam. A README.md should briefly describe the project, its purpose, and provide clear instructions to help developers, contributors, and stakeholders navigate and use the repository effectively. diff --git a/docs/general/secure-coding.md b/docs/general/secure-coding.md index 77df153..3c5e5e5 100644 --- a/docs/general/secure-coding.md +++ b/docs/general/secure-coding.md @@ -1,6 +1,4 @@ # Secure coding -> -> This page was last reviewed January 16th 2025. It needs to be reviewed again on October 16th 2025. ## What is the standard for secure coding? diff --git a/docs/general/storing-source-code.md b/docs/general/storing-source-code.md index 8165038..fd261cc 100644 --- a/docs/general/storing-source-code.md +++ b/docs/general/storing-source-code.md @@ -1,15 +1,17 @@ # Store your project in GitHub -> This page was last reviewed January 21st 2025. It needs to be reviewed again on October 21st, 2025. ## How to store projects on Github? - All projects must have their repository on GitHub in the account of the city of Amsterdam and should be public, see the section "Public or private" for allowed exemptions. -- You must use Git to store your code on GitHub. Include a CODEOWNER file with your team name in the source code. See [the EE-docs repository](https://github.com/Amsterdam/ee-docs/blob/develop/CODEOWNERS) for an example. +- You must use Git to store your code on GitHub. Include a CODEOWNERS file with your team name in the source code. See [the EE-docs repository](https://github.com/Amsterdam/ee-docs/blob/develop/CODEOWNERS) for an example. - Secure your repository by enabling these branch protection rules: - Require a pull request before merging - Require approvals - The required number of approvals before merging is at least 1 +### Sign your commits +We recommend signing your commits, as it enhances both reliability and security. [You can use](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification) either GPG ([GNU Privacy Guard](https://www.gnupg.org/)) or SSH; you simply need to inform Git which key you are using. Setting up a GPG signature can be somewhat [complex](https://docs.github.com/en/authentication/managing-commit-signature-verification/generating-a-new-gpg-key), so we recommend using [an SSH key](https://stackoverflow.com/questions/72844616/how-do-i-sign-git-commits-using-my-existing-ssh-key) instead. + ## When and for whom is this standard? This standard applies to all developers.
This standard must be applied to all new repositories of the city of Amsterdam (new since May 2024). @@ -19,7 +21,7 @@ Infra-as-code logic must always be stored in a private repository. This improves transparency and reusability, but protects us from exposing sensitive information that could benefit potential bad actors. -## Recommendations +## Recommendations - Send an e-mail to github@amsterdam.nl to get in touch with the Engineering Enablement team to access the Amsterdam organization in GitHub. Your e-mail must include the following: - The GitHub username(s). - The user(s) first and last name(s). @@ -35,10 +37,10 @@ but protects us from exposing sensitive information that could benefit potential ## Further reading - [The GitHub documentation](https://docs.github.com/en/get-started) is a good source of information. -- [GitHub](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) also has information about CODEOWNER files. +- [GitHub](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) also has information about CODEOWNERS files. ## Acknowledgments -Many thanks to [Hee Chan van der Haar](https://github.com/hcvdhaar), [Benny van de Hoogen](https://github.com/bennyvdhoogen) and [Sirée Koolen-Wijkstra](https://github.com/SireeKoolenWijkstra) +Many thanks to [Hee Chan van der Haar](https://github.com/hcvdhaar), [Benny van de Hoogen](https://github.com/bennyvdhoogen), [Youri Westerman](https://github.com/4c0n) and [Sirée Koolen-Wijkstra](https://github.com/SireeKoolenWijkstra) ## Further reading -- Want to know more about the Fork and Pull model? We recommend you read [the GitHub Docs](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/getting-started/about-collaborative-development-models#fork-and-pull-model). \ No newline at end of file +- Want to know more about the Fork and Pull model? We recommend you read [the GitHub Docs](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/getting-started/about-collaborative-development-models#fork-and-pull-model). diff --git a/docs/general/testing.md b/docs/general/testing.md index 5ab9c73..656c392 100644 --- a/docs/general/testing.md +++ b/docs/general/testing.md @@ -1,7 +1,5 @@ # Testing -> This page was last reviewed October the 14th August 2024. It needs to be reviewed again on April 14th 2025. - ## What is the standard for testing? Every production ready project needs to have unit and integration tests included. Developers are responsible for writing and maintaining these tests. @@ -13,9 +11,9 @@ This standard applies to all developers. - [ ] the baseline for code coverage. - [ ] how to integrate the tests in the deployment pipeline. - [ ] how to structure test files, mocks and stubs. -- [ ] Use either Jest or Vitest and React Testing Library as your test framework for front-end projects. +- [ ] Use either Jest or Vitest and React Testing Library as your test framework for front-end projects. - [ ] Use Django's built-in testing framework for back-end projects using Django and Python. -- [ ] use either Playwright or Cypress for regression tests. +- [ ] use either Playwright or Cypress for regression tests. ## What to avoid? - Don't treat testing as an afterthought. @@ -30,7 +28,7 @@ This standard applies to all developers. - The Vakgroep requires a minimum code coverage of 80% for new backend projects. For legacy applications this standard applies only to new code or features wherever feasible. ### End-to-end testing (E2E testing) -E2E testing is not mandatory. The Vakgroep employs two dedicated testers who can assist in creating and running e2e tests. Your Product Owner would need to contact the Vakgroep to inquire about the possibilities. +E2E testing is not mandatory. The Vakgroep employs a dedicated tester who can assist in creating and running e2e tests. Your Product Owner should contact the Vakgroep to explore the available options. ### Snapshot testing Snapshot testing ensures that the UI did not unexpectedly change compared to the previous state of the rendered output. It is recommended to use either [Jest](https://jestjs.io/) or [Vitest](https://vitest.dev/) together with [react-test-renderer](https://npmjs.com/package/react-test-renderer). diff --git a/docs/general/third-party-dependencies.md b/docs/general/third-party-dependencies.md index 80bb0b0..e908ca0 100644 --- a/docs/general/third-party-dependencies.md +++ b/docs/general/third-party-dependencies.md @@ -1,7 +1,5 @@ # Third Party Dependencies -> This page was last reviewed on July 8th, 2025. It needs to be reviewed again on April 8th, 2026. - Third party dependencies can be introduced via: * using a dependency management tool (for example, [Composer for PHP](https://getcomposer.org/), [NPM for JavaScript](https://www.npmjs.com/) and [Poetry for Python](https://python-poetry.org/)) diff --git a/docs/general/using-git.md b/docs/general/using-git.md index e7aa640..098669e 100644 --- a/docs/general/using-git.md +++ b/docs/general/using-git.md @@ -1,5 +1,4 @@ # Using Git -> This page was last reviewed 13 February 2025. It needs to be reviewed again on 13 November 2025. ## What is the standard for using Git? The city of Amsterdam uses Git to push its code to GitHub. diff --git a/docs/intro.md b/docs/intro.md index 72f70de..9159f64 100644 --- a/docs/intro.md +++ b/docs/intro.md @@ -3,7 +3,7 @@ sidebar_position: 1 --- # Collaborating on standards -> This page was last reviewed on July 8th, 2025. It needs to be reviewed again on April 8th, 2026. +> This page was last reviewed on October 28th, 2024. It needs to be reviewed again on July 28th, 2025. ## Empowering Contribution: Your Guide to Success From 18286f5a39b4657db70d69601d0b1cc8d457273c Mon Sep 17 00:00:00 2001 From: Abdellah Date: Tue, 3 Mar 2026 15:40:32 +0100 Subject: [PATCH 2/4] Revert "update: deleting the review dates" This reverts commit fdf66df52721bab7bc97b3cf7a1264a54b19a8c8. --- docs/CODEOWNERS | 1 - docs/backend/database.md | 1 + docs/backend/docker-usage.md | 5 +++-- docs/backend/handling-access-tokens.md | 1 + docs/frontend/accessibility.md | 2 ++ docs/frontend/third-party-dependencies.md | 2 ++ docs/general/github-copilot.md | 7 ------- docs/general/languages-and-frameworks.md | 2 ++ docs/general/project-documentation.md | 1 + docs/general/readme-default.md | 2 ++ docs/general/secure-coding.md | 2 ++ docs/general/storing-source-code.md | 14 ++++++-------- docs/general/testing.md | 8 +++++--- docs/general/third-party-dependencies.md | 2 ++ docs/general/using-git.md | 1 + docs/intro.md | 2 +- 16 files changed, 31 insertions(+), 22 deletions(-) delete mode 100644 docs/CODEOWNERS delete mode 100644 docs/general/github-copilot.md diff --git a/docs/CODEOWNERS b/docs/CODEOWNERS deleted file mode 100644 index ed93980..0000000 --- a/docs/CODEOWNERS +++ /dev/null @@ -1 +0,0 @@ -* @Amsterdam/enablement \ No newline at end of file diff --git a/docs/backend/database.md b/docs/backend/database.md index ef3bc16..984bd5c 100644 --- a/docs/backend/database.md +++ b/docs/backend/database.md @@ -1,4 +1,5 @@ # Database +> This page was last reviewed on 27-08-2025. It needs to be reviewed again on 27-05-2026. The database is quite often at the core of our applications. It is used to store and query data. While this data will be structured most of the time, sometimes it is useful to be able to store diff --git a/docs/backend/docker-usage.md b/docs/backend/docker-usage.md index 02fe8e0..2a3c099 100644 --- a/docs/backend/docker-usage.md +++ b/docs/backend/docker-usage.md @@ -1,9 +1,10 @@ # Docker usage +> This page was last reviewed July 8th, 2025. It needs to be reviewed again on April 8th, 2026. ## What is the standard for Docker? Use Docker for containerization in the development, testing, and production of applications within the Municipality. Developers must use Dockerfiles that meet the minimum requirements outlined below. Dockerfiles are stored in the application repository in **GitHub**, while the compiled Docker images are stored in **Azure Container Registry (ACR)**. ## When and for whom is this standard applicable? -This guideline applies to all developers (front-end and back-end), IT administrators, and DevOps teams within the Municipality. It applies to all projects. +This guideline applies to all developers (front-end and back-end), IT administrators, and DevOps teams within the Municipality. It applies to all projects. Projects that started before September 2024 with a different configuration must be adapted to this standard. ## What is required when using Docker? @@ -11,7 +12,7 @@ This guideline applies to all developers (front-end and back-end), IT administra - [ ] **Base Image**: Use well-known and well-maintained base images and make sure that the version number is the latest, otherwise -2/-3 of the latest version. In addition, it is of high importance that the version number should **never** explicitly state `latest`. The most commonly used images are: Alpine, NGINX, Node.js, PHP, Postgres, Python and Ubuntu. - [ ] **Minimal Installations**: Limit the installation of additional packages to what is strictly necessary to keep the image lightweight and secure. - [ ] **Version Control**: Explicitly specify the versions of all dependencies to ensure consistency. -- **Docker Image Storage**: Dockerfiles must be stored in the application repository in **GitHub**. The compiled Docker images must be stored in **ACR**. **Docker Hub** is to be used only in approved situations where an image needs to be shared between multiple teams or municipalities. +- **Docker Image Storage**: Dockerfiles must be stored in the application repository in **GitHub**. The compiled Docker images must be stored in **ACR**. Only in cases where an image is shared across multiple teams or other municipalities may **Docker Hub** be used. ## Standard ADO Pipelines diff --git a/docs/backend/handling-access-tokens.md b/docs/backend/handling-access-tokens.md index 90c75f4..02de6ad 100644 --- a/docs/backend/handling-access-tokens.md +++ b/docs/backend/handling-access-tokens.md @@ -1,4 +1,5 @@ # Handling Access Tokens +> This page was last reviewed on 10-09-2025. It needs to be reviewed again on 10-06-2026. A common requirement for our applications is that we need to implement authentication. We typically do that by implementing OpenId Connect (OIDC) support. diff --git a/docs/frontend/accessibility.md b/docs/frontend/accessibility.md index 963165a..ad416be 100644 --- a/docs/frontend/accessibility.md +++ b/docs/frontend/accessibility.md @@ -1,5 +1,7 @@ # Accessibility +> This page was last reviewed on 6 February 2025. It needs to be reviewed again on 6 November 2025. + ## What is the standard for accessibility? In accordance with the Digital Government Act, the municipality of Amsterdam is required to build all its websites and applications in compliance with the Web Content Accessibility Guidelines (WCAG) 2.1 at AA level. diff --git a/docs/frontend/third-party-dependencies.md b/docs/frontend/third-party-dependencies.md index 96e3d30..a44efd4 100644 --- a/docs/frontend/third-party-dependencies.md +++ b/docs/frontend/third-party-dependencies.md @@ -1,5 +1,7 @@ # Third Party Dependencies +> This page was last reviewed on July 8th, 2025. It needs to be reviewed again on April 8th, 2026. + Guidelines for choosing a third party package can be found in the [general third party dependencies documentation page](../general/third-party-dependencies.md). ## How can you secure front-end third-party integrations? diff --git a/docs/general/github-copilot.md b/docs/general/github-copilot.md deleted file mode 100644 index 73ee806..0000000 --- a/docs/general/github-copilot.md +++ /dev/null @@ -1,7 +0,0 @@ -# GitHub Copilot Usage Rules - -This document provides the standard for using GitHub Copilot within our organization. It outlines the rules, guidelines, and best practices to ensure Copilot is used safely and responsibly, while maintaining software quality and compliance with our internal policies. By following these rules, developers can benefit from Copilot while reducing risks related to personal data, bias, and insufficient testing. - -Please note that this documentation is only visible to developers who have access to the Amsterdam organization in GitHub. - -For more details and the full documentation, please visit the official repository via the following link: [GitHub Copilot Usage Rules](https://github.com/Amsterdam/development-standards/tree/main/internal/github-copilot.md). diff --git a/docs/general/languages-and-frameworks.md b/docs/general/languages-and-frameworks.md index f9320f6..78765b0 100644 --- a/docs/general/languages-and-frameworks.md +++ b/docs/general/languages-and-frameworks.md @@ -1,5 +1,7 @@ # Languages & Frameworks for Software Development +> This page was last reviewed on 10th April. It needs to be reviewed again on 10th January 2026. + ## What is the standard? ### Backend diff --git a/docs/general/project-documentation.md b/docs/general/project-documentation.md index 7ffd441..a652479 100644 --- a/docs/general/project-documentation.md +++ b/docs/general/project-documentation.md @@ -1,4 +1,5 @@ # Documentation +> This page was last reviewed 13 February 2025. It needs to be reviewed again on 13 November 2025. ## What is the standard for documentation? Include documentation in your project that facilitates understanding, usage, and maintenance of your code. The documentation should promote usability and longevity of your project, and effective collaboration among your stakeholders. diff --git a/docs/general/readme-default.md b/docs/general/readme-default.md index fb7dd3d..194cf50 100644 --- a/docs/general/readme-default.md +++ b/docs/general/readme-default.md @@ -1,5 +1,7 @@ # Readme files +> This page was last reviewed on February 3rd, 2025. It needs to be reviewed again on November 3rd, 2025. + ## What is the standard for a README for the city of Amsterdam? There must be a README.md file for every Github repository of the city of Amsterdam. A README.md should briefly describe the project, its purpose, and provide clear instructions to help developers, contributors, and stakeholders navigate and use the repository effectively. diff --git a/docs/general/secure-coding.md b/docs/general/secure-coding.md index 3c5e5e5..77df153 100644 --- a/docs/general/secure-coding.md +++ b/docs/general/secure-coding.md @@ -1,4 +1,6 @@ # Secure coding +> +> This page was last reviewed January 16th 2025. It needs to be reviewed again on October 16th 2025. ## What is the standard for secure coding? diff --git a/docs/general/storing-source-code.md b/docs/general/storing-source-code.md index fd261cc..8165038 100644 --- a/docs/general/storing-source-code.md +++ b/docs/general/storing-source-code.md @@ -1,17 +1,15 @@ # Store your project in GitHub +> This page was last reviewed January 21st 2025. It needs to be reviewed again on October 21st, 2025. ## How to store projects on Github? - All projects must have their repository on GitHub in the account of the city of Amsterdam and should be public, see the section "Public or private" for allowed exemptions. -- You must use Git to store your code on GitHub. Include a CODEOWNERS file with your team name in the source code. See [the EE-docs repository](https://github.com/Amsterdam/ee-docs/blob/develop/CODEOWNERS) for an example. +- You must use Git to store your code on GitHub. Include a CODEOWNER file with your team name in the source code. See [the EE-docs repository](https://github.com/Amsterdam/ee-docs/blob/develop/CODEOWNERS) for an example. - Secure your repository by enabling these branch protection rules: - Require a pull request before merging - Require approvals - The required number of approvals before merging is at least 1 -### Sign your commits -We recommend signing your commits, as it enhances both reliability and security. [You can use](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification) either GPG ([GNU Privacy Guard](https://www.gnupg.org/)) or SSH; you simply need to inform Git which key you are using. Setting up a GPG signature can be somewhat [complex](https://docs.github.com/en/authentication/managing-commit-signature-verification/generating-a-new-gpg-key), so we recommend using [an SSH key](https://stackoverflow.com/questions/72844616/how-do-i-sign-git-commits-using-my-existing-ssh-key) instead. - ## When and for whom is this standard? This standard applies to all developers.
This standard must be applied to all new repositories of the city of Amsterdam (new since May 2024). @@ -21,7 +19,7 @@ Infra-as-code logic must always be stored in a private repository. This improves transparency and reusability, but protects us from exposing sensitive information that could benefit potential bad actors. -## Recommendations +## Recommendations - Send an e-mail to github@amsterdam.nl to get in touch with the Engineering Enablement team to access the Amsterdam organization in GitHub. Your e-mail must include the following: - The GitHub username(s). - The user(s) first and last name(s). @@ -37,10 +35,10 @@ but protects us from exposing sensitive information that could benefit potential ## Further reading - [The GitHub documentation](https://docs.github.com/en/get-started) is a good source of information. -- [GitHub](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) also has information about CODEOWNERS files. +- [GitHub](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) also has information about CODEOWNER files. ## Acknowledgments -Many thanks to [Hee Chan van der Haar](https://github.com/hcvdhaar), [Benny van de Hoogen](https://github.com/bennyvdhoogen), [Youri Westerman](https://github.com/4c0n) and [Sirée Koolen-Wijkstra](https://github.com/SireeKoolenWijkstra) +Many thanks to [Hee Chan van der Haar](https://github.com/hcvdhaar), [Benny van de Hoogen](https://github.com/bennyvdhoogen) and [Sirée Koolen-Wijkstra](https://github.com/SireeKoolenWijkstra) ## Further reading -- Want to know more about the Fork and Pull model? We recommend you read [the GitHub Docs](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/getting-started/about-collaborative-development-models#fork-and-pull-model). +- Want to know more about the Fork and Pull model? We recommend you read [the GitHub Docs](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/getting-started/about-collaborative-development-models#fork-and-pull-model). \ No newline at end of file diff --git a/docs/general/testing.md b/docs/general/testing.md index 656c392..5ab9c73 100644 --- a/docs/general/testing.md +++ b/docs/general/testing.md @@ -1,5 +1,7 @@ # Testing +> This page was last reviewed October the 14th August 2024. It needs to be reviewed again on April 14th 2025. + ## What is the standard for testing? Every production ready project needs to have unit and integration tests included. Developers are responsible for writing and maintaining these tests. @@ -11,9 +13,9 @@ This standard applies to all developers. - [ ] the baseline for code coverage. - [ ] how to integrate the tests in the deployment pipeline. - [ ] how to structure test files, mocks and stubs. -- [ ] Use either Jest or Vitest and React Testing Library as your test framework for front-end projects. +- [ ] Use either Jest or Vitest and React Testing Library as your test framework for front-end projects. - [ ] Use Django's built-in testing framework for back-end projects using Django and Python. -- [ ] use either Playwright or Cypress for regression tests. +- [ ] use either Playwright or Cypress for regression tests. ## What to avoid? - Don't treat testing as an afterthought. @@ -28,7 +30,7 @@ This standard applies to all developers. - The Vakgroep requires a minimum code coverage of 80% for new backend projects. For legacy applications this standard applies only to new code or features wherever feasible. ### End-to-end testing (E2E testing) -E2E testing is not mandatory. The Vakgroep employs a dedicated tester who can assist in creating and running e2e tests. Your Product Owner should contact the Vakgroep to explore the available options. +E2E testing is not mandatory. The Vakgroep employs two dedicated testers who can assist in creating and running e2e tests. Your Product Owner would need to contact the Vakgroep to inquire about the possibilities. ### Snapshot testing Snapshot testing ensures that the UI did not unexpectedly change compared to the previous state of the rendered output. It is recommended to use either [Jest](https://jestjs.io/) or [Vitest](https://vitest.dev/) together with [react-test-renderer](https://npmjs.com/package/react-test-renderer). diff --git a/docs/general/third-party-dependencies.md b/docs/general/third-party-dependencies.md index e908ca0..80bb0b0 100644 --- a/docs/general/third-party-dependencies.md +++ b/docs/general/third-party-dependencies.md @@ -1,5 +1,7 @@ # Third Party Dependencies +> This page was last reviewed on July 8th, 2025. It needs to be reviewed again on April 8th, 2026. + Third party dependencies can be introduced via: * using a dependency management tool (for example, [Composer for PHP](https://getcomposer.org/), [NPM for JavaScript](https://www.npmjs.com/) and [Poetry for Python](https://python-poetry.org/)) diff --git a/docs/general/using-git.md b/docs/general/using-git.md index 098669e..e7aa640 100644 --- a/docs/general/using-git.md +++ b/docs/general/using-git.md @@ -1,4 +1,5 @@ # Using Git +> This page was last reviewed 13 February 2025. It needs to be reviewed again on 13 November 2025. ## What is the standard for using Git? The city of Amsterdam uses Git to push its code to GitHub. diff --git a/docs/intro.md b/docs/intro.md index 9159f64..72f70de 100644 --- a/docs/intro.md +++ b/docs/intro.md @@ -3,7 +3,7 @@ sidebar_position: 1 --- # Collaborating on standards -> This page was last reviewed on October 28th, 2024. It needs to be reviewed again on July 28th, 2025. +> This page was last reviewed on July 8th, 2025. It needs to be reviewed again on April 8th, 2026. ## Empowering Contribution: Your Guide to Success From 37ab551fa6253aa9ddd7c99336ebf8ec609c9764 Mon Sep 17 00:00:00 2001 From: amnad001 Date: Wed, 4 Mar 2026 17:17:56 +0100 Subject: [PATCH 3/4] Update/deleting last dates (#199) * update: deleting the review dates * Revert "update: deleting the review dates" This reverts commit fdf66df52721bab7bc97b3cf7a1264a54b19a8c8. * Deleting the review dates * Adding github copilot documentation * Made the sidebar alfabatical * Made it alphabetical * Merge conflict --------- Co-authored-by: Abdellah --- docs/CODEOWNERS | 1 + docs/backend/database.md | 1 - docs/backend/docker-usage.md | 5 +- docs/backend/handling-access-tokens.md | 1 - docs/frontend/accessibility.md | 2 - docs/frontend/third-party-dependencies.md | 2 - docs/general/github-copilot.md | 7 +++ docs/general/languages-and-frameworks.md | 2 - docs/general/project-documentation.md | 1 - docs/general/readme-default.md | 2 - docs/general/secure-coding.md | 2 - docs/general/storing-source-code.md | 14 ++--- docs/general/testing.md | 8 ++- docs/general/third-party-dependencies.md | 2 - docs/general/using-git.md | 1 - docs/intro.md | 2 - sidebars.ts | 1 + test.yaml | 66 +++++++++++++++++++++++ 18 files changed, 88 insertions(+), 32 deletions(-) create mode 100644 docs/CODEOWNERS create mode 100644 docs/general/github-copilot.md create mode 100644 test.yaml diff --git a/docs/CODEOWNERS b/docs/CODEOWNERS new file mode 100644 index 0000000..ed93980 --- /dev/null +++ b/docs/CODEOWNERS @@ -0,0 +1 @@ +* @Amsterdam/enablement \ No newline at end of file diff --git a/docs/backend/database.md b/docs/backend/database.md index 984bd5c..ef3bc16 100644 --- a/docs/backend/database.md +++ b/docs/backend/database.md @@ -1,5 +1,4 @@ # Database -> This page was last reviewed on 27-08-2025. It needs to be reviewed again on 27-05-2026. The database is quite often at the core of our applications. It is used to store and query data. While this data will be structured most of the time, sometimes it is useful to be able to store diff --git a/docs/backend/docker-usage.md b/docs/backend/docker-usage.md index 2a3c099..02fe8e0 100644 --- a/docs/backend/docker-usage.md +++ b/docs/backend/docker-usage.md @@ -1,10 +1,9 @@ # Docker usage -> This page was last reviewed July 8th, 2025. It needs to be reviewed again on April 8th, 2026. ## What is the standard for Docker? Use Docker for containerization in the development, testing, and production of applications within the Municipality. Developers must use Dockerfiles that meet the minimum requirements outlined below. Dockerfiles are stored in the application repository in **GitHub**, while the compiled Docker images are stored in **Azure Container Registry (ACR)**. ## When and for whom is this standard applicable? -This guideline applies to all developers (front-end and back-end), IT administrators, and DevOps teams within the Municipality. It applies to all projects. Projects that started before September 2024 with a different configuration must be adapted to this standard. +This guideline applies to all developers (front-end and back-end), IT administrators, and DevOps teams within the Municipality. It applies to all projects. ## What is required when using Docker? @@ -12,7 +11,7 @@ This guideline applies to all developers (front-end and back-end), IT administra - [ ] **Base Image**: Use well-known and well-maintained base images and make sure that the version number is the latest, otherwise -2/-3 of the latest version. In addition, it is of high importance that the version number should **never** explicitly state `latest`. The most commonly used images are: Alpine, NGINX, Node.js, PHP, Postgres, Python and Ubuntu. - [ ] **Minimal Installations**: Limit the installation of additional packages to what is strictly necessary to keep the image lightweight and secure. - [ ] **Version Control**: Explicitly specify the versions of all dependencies to ensure consistency. -- **Docker Image Storage**: Dockerfiles must be stored in the application repository in **GitHub**. The compiled Docker images must be stored in **ACR**. Only in cases where an image is shared across multiple teams or other municipalities may **Docker Hub** be used. +- **Docker Image Storage**: Dockerfiles must be stored in the application repository in **GitHub**. The compiled Docker images must be stored in **ACR**. **Docker Hub** is to be used only in approved situations where an image needs to be shared between multiple teams or municipalities. ## Standard ADO Pipelines diff --git a/docs/backend/handling-access-tokens.md b/docs/backend/handling-access-tokens.md index 02de6ad..90c75f4 100644 --- a/docs/backend/handling-access-tokens.md +++ b/docs/backend/handling-access-tokens.md @@ -1,5 +1,4 @@ # Handling Access Tokens -> This page was last reviewed on 10-09-2025. It needs to be reviewed again on 10-06-2026. A common requirement for our applications is that we need to implement authentication. We typically do that by implementing OpenId Connect (OIDC) support. diff --git a/docs/frontend/accessibility.md b/docs/frontend/accessibility.md index ad416be..963165a 100644 --- a/docs/frontend/accessibility.md +++ b/docs/frontend/accessibility.md @@ -1,7 +1,5 @@ # Accessibility -> This page was last reviewed on 6 February 2025. It needs to be reviewed again on 6 November 2025. - ## What is the standard for accessibility? In accordance with the Digital Government Act, the municipality of Amsterdam is required to build all its websites and applications in compliance with the Web Content Accessibility Guidelines (WCAG) 2.1 at AA level. diff --git a/docs/frontend/third-party-dependencies.md b/docs/frontend/third-party-dependencies.md index a44efd4..96e3d30 100644 --- a/docs/frontend/third-party-dependencies.md +++ b/docs/frontend/third-party-dependencies.md @@ -1,7 +1,5 @@ # Third Party Dependencies -> This page was last reviewed on July 8th, 2025. It needs to be reviewed again on April 8th, 2026. - Guidelines for choosing a third party package can be found in the [general third party dependencies documentation page](../general/third-party-dependencies.md). ## How can you secure front-end third-party integrations? diff --git a/docs/general/github-copilot.md b/docs/general/github-copilot.md new file mode 100644 index 0000000..73ee806 --- /dev/null +++ b/docs/general/github-copilot.md @@ -0,0 +1,7 @@ +# GitHub Copilot Usage Rules + +This document provides the standard for using GitHub Copilot within our organization. It outlines the rules, guidelines, and best practices to ensure Copilot is used safely and responsibly, while maintaining software quality and compliance with our internal policies. By following these rules, developers can benefit from Copilot while reducing risks related to personal data, bias, and insufficient testing. + +Please note that this documentation is only visible to developers who have access to the Amsterdam organization in GitHub. + +For more details and the full documentation, please visit the official repository via the following link: [GitHub Copilot Usage Rules](https://github.com/Amsterdam/development-standards/tree/main/internal/github-copilot.md). diff --git a/docs/general/languages-and-frameworks.md b/docs/general/languages-and-frameworks.md index 78765b0..f9320f6 100644 --- a/docs/general/languages-and-frameworks.md +++ b/docs/general/languages-and-frameworks.md @@ -1,7 +1,5 @@ # Languages & Frameworks for Software Development -> This page was last reviewed on 10th April. It needs to be reviewed again on 10th January 2026. - ## What is the standard? ### Backend diff --git a/docs/general/project-documentation.md b/docs/general/project-documentation.md index a652479..7ffd441 100644 --- a/docs/general/project-documentation.md +++ b/docs/general/project-documentation.md @@ -1,5 +1,4 @@ # Documentation -> This page was last reviewed 13 February 2025. It needs to be reviewed again on 13 November 2025. ## What is the standard for documentation? Include documentation in your project that facilitates understanding, usage, and maintenance of your code. The documentation should promote usability and longevity of your project, and effective collaboration among your stakeholders. diff --git a/docs/general/readme-default.md b/docs/general/readme-default.md index 194cf50..fb7dd3d 100644 --- a/docs/general/readme-default.md +++ b/docs/general/readme-default.md @@ -1,7 +1,5 @@ # Readme files -> This page was last reviewed on February 3rd, 2025. It needs to be reviewed again on November 3rd, 2025. - ## What is the standard for a README for the city of Amsterdam? There must be a README.md file for every Github repository of the city of Amsterdam. A README.md should briefly describe the project, its purpose, and provide clear instructions to help developers, contributors, and stakeholders navigate and use the repository effectively. diff --git a/docs/general/secure-coding.md b/docs/general/secure-coding.md index 77df153..3c5e5e5 100644 --- a/docs/general/secure-coding.md +++ b/docs/general/secure-coding.md @@ -1,6 +1,4 @@ # Secure coding -> -> This page was last reviewed January 16th 2025. It needs to be reviewed again on October 16th 2025. ## What is the standard for secure coding? diff --git a/docs/general/storing-source-code.md b/docs/general/storing-source-code.md index 8165038..fd261cc 100644 --- a/docs/general/storing-source-code.md +++ b/docs/general/storing-source-code.md @@ -1,15 +1,17 @@ # Store your project in GitHub -> This page was last reviewed January 21st 2025. It needs to be reviewed again on October 21st, 2025. ## How to store projects on Github? - All projects must have their repository on GitHub in the account of the city of Amsterdam and should be public, see the section "Public or private" for allowed exemptions. -- You must use Git to store your code on GitHub. Include a CODEOWNER file with your team name in the source code. See [the EE-docs repository](https://github.com/Amsterdam/ee-docs/blob/develop/CODEOWNERS) for an example. +- You must use Git to store your code on GitHub. Include a CODEOWNERS file with your team name in the source code. See [the EE-docs repository](https://github.com/Amsterdam/ee-docs/blob/develop/CODEOWNERS) for an example. - Secure your repository by enabling these branch protection rules: - Require a pull request before merging - Require approvals - The required number of approvals before merging is at least 1 +### Sign your commits +We recommend signing your commits, as it enhances both reliability and security. [You can use](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification) either GPG ([GNU Privacy Guard](https://www.gnupg.org/)) or SSH; you simply need to inform Git which key you are using. Setting up a GPG signature can be somewhat [complex](https://docs.github.com/en/authentication/managing-commit-signature-verification/generating-a-new-gpg-key), so we recommend using [an SSH key](https://stackoverflow.com/questions/72844616/how-do-i-sign-git-commits-using-my-existing-ssh-key) instead. + ## When and for whom is this standard? This standard applies to all developers.
This standard must be applied to all new repositories of the city of Amsterdam (new since May 2024). @@ -19,7 +21,7 @@ Infra-as-code logic must always be stored in a private repository. This improves transparency and reusability, but protects us from exposing sensitive information that could benefit potential bad actors. -## Recommendations +## Recommendations - Send an e-mail to github@amsterdam.nl to get in touch with the Engineering Enablement team to access the Amsterdam organization in GitHub. Your e-mail must include the following: - The GitHub username(s). - The user(s) first and last name(s). @@ -35,10 +37,10 @@ but protects us from exposing sensitive information that could benefit potential ## Further reading - [The GitHub documentation](https://docs.github.com/en/get-started) is a good source of information. -- [GitHub](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) also has information about CODEOWNER files. +- [GitHub](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) also has information about CODEOWNERS files. ## Acknowledgments -Many thanks to [Hee Chan van der Haar](https://github.com/hcvdhaar), [Benny van de Hoogen](https://github.com/bennyvdhoogen) and [Sirée Koolen-Wijkstra](https://github.com/SireeKoolenWijkstra) +Many thanks to [Hee Chan van der Haar](https://github.com/hcvdhaar), [Benny van de Hoogen](https://github.com/bennyvdhoogen), [Youri Westerman](https://github.com/4c0n) and [Sirée Koolen-Wijkstra](https://github.com/SireeKoolenWijkstra) ## Further reading -- Want to know more about the Fork and Pull model? We recommend you read [the GitHub Docs](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/getting-started/about-collaborative-development-models#fork-and-pull-model). \ No newline at end of file +- Want to know more about the Fork and Pull model? We recommend you read [the GitHub Docs](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/getting-started/about-collaborative-development-models#fork-and-pull-model). diff --git a/docs/general/testing.md b/docs/general/testing.md index 5ab9c73..656c392 100644 --- a/docs/general/testing.md +++ b/docs/general/testing.md @@ -1,7 +1,5 @@ # Testing -> This page was last reviewed October the 14th August 2024. It needs to be reviewed again on April 14th 2025. - ## What is the standard for testing? Every production ready project needs to have unit and integration tests included. Developers are responsible for writing and maintaining these tests. @@ -13,9 +11,9 @@ This standard applies to all developers. - [ ] the baseline for code coverage. - [ ] how to integrate the tests in the deployment pipeline. - [ ] how to structure test files, mocks and stubs. -- [ ] Use either Jest or Vitest and React Testing Library as your test framework for front-end projects. +- [ ] Use either Jest or Vitest and React Testing Library as your test framework for front-end projects. - [ ] Use Django's built-in testing framework for back-end projects using Django and Python. -- [ ] use either Playwright or Cypress for regression tests. +- [ ] use either Playwright or Cypress for regression tests. ## What to avoid? - Don't treat testing as an afterthought. @@ -30,7 +28,7 @@ This standard applies to all developers. - The Vakgroep requires a minimum code coverage of 80% for new backend projects. For legacy applications this standard applies only to new code or features wherever feasible. ### End-to-end testing (E2E testing) -E2E testing is not mandatory. The Vakgroep employs two dedicated testers who can assist in creating and running e2e tests. Your Product Owner would need to contact the Vakgroep to inquire about the possibilities. +E2E testing is not mandatory. The Vakgroep employs a dedicated tester who can assist in creating and running e2e tests. Your Product Owner should contact the Vakgroep to explore the available options. ### Snapshot testing Snapshot testing ensures that the UI did not unexpectedly change compared to the previous state of the rendered output. It is recommended to use either [Jest](https://jestjs.io/) or [Vitest](https://vitest.dev/) together with [react-test-renderer](https://npmjs.com/package/react-test-renderer). diff --git a/docs/general/third-party-dependencies.md b/docs/general/third-party-dependencies.md index 80bb0b0..e908ca0 100644 --- a/docs/general/third-party-dependencies.md +++ b/docs/general/third-party-dependencies.md @@ -1,7 +1,5 @@ # Third Party Dependencies -> This page was last reviewed on July 8th, 2025. It needs to be reviewed again on April 8th, 2026. - Third party dependencies can be introduced via: * using a dependency management tool (for example, [Composer for PHP](https://getcomposer.org/), [NPM for JavaScript](https://www.npmjs.com/) and [Poetry for Python](https://python-poetry.org/)) diff --git a/docs/general/using-git.md b/docs/general/using-git.md index e7aa640..098669e 100644 --- a/docs/general/using-git.md +++ b/docs/general/using-git.md @@ -1,5 +1,4 @@ # Using Git -> This page was last reviewed 13 February 2025. It needs to be reviewed again on 13 November 2025. ## What is the standard for using Git? The city of Amsterdam uses Git to push its code to GitHub. diff --git a/docs/intro.md b/docs/intro.md index 72f70de..1f721c5 100644 --- a/docs/intro.md +++ b/docs/intro.md @@ -3,8 +3,6 @@ sidebar_position: 1 --- # Collaborating on standards -> This page was last reviewed on July 8th, 2025. It needs to be reviewed again on April 8th, 2026. - ## Empowering Contribution: Your Guide to Success We're thrilled you're interested in contributing to our development community! The Engineering Enablement team is dedicated to supporting you throughout your journey. Should you ever feel daunted by the contribution process, don't hesitate to take a breather, and we'll be ready to assist you further. Your involvement is valued, and we're here to help. diff --git a/sidebars.ts b/sidebars.ts index 05cf30d..dfc1280 100644 --- a/sidebars.ts +++ b/sidebars.ts @@ -20,6 +20,7 @@ const sidebars: SidebarsConfig = { label: 'Common standards', items: [ 'general/project-documentation', + 'general/github-copilot', 'general/languages-and-frameworks', 'tech-stack/tech-stack', 'general/readme-default', diff --git a/test.yaml b/test.yaml new file mode 100644 index 0000000..cc36578 --- /dev/null +++ b/test.yaml @@ -0,0 +1,66 @@ + +- job: + displayName: 'jira webhook' + steps: + - checkout: self + - ${{ if eq(parameters.acc, true) }}: + - task: AzurePowerShell@5 + inputs: + azureSubscription: 'ARM-CCC-OPDR-ont-01' + ScriptType: 'InlineScript' + Inline: | + $resourceGroupName = 'shared-o-rg' + + $KeyVault = Get-AzResource -ResourceGroupName $resourceGroupName | Where-Object { + $_.ResourceType -eq "Microsoft.KeyVault/vaults" -and $_.Name -like "shared-o-*" + } + + $KeyVaultName = $KeyVault.Name + + $certificates = Get-AzKeyVaultCertificate -VaultName $KeyVaultName + + $currentDate = Get-Date + + $filteredCertificates = $certificates | Where-Object { + $_.Expires -gt $currentDate.AddDays(100) -and $_.Expires -lt $currentDate.AddDays(120) + } + + Write-Host "The certs to expire:" + $filteredCertificates + + Write-Host "Attempting Jira webhook:" + + $jiraWebhookUrl = 'https://api-private.atlassian.com/automation/webhooks/jira/a/f8771ef1-0a37-46ae-b72a-4f2586b482e2/01958f14-e3bc-7725-b7dd-f9a80dbf097b' + $jiraWebhookSecret = '57da1cd12db225cbe627ef2d6e4ad497ff54f1db' + + foreach ($certificate in $filteredCertificates) { + $expiryDate = Get-Date $certificate.Expires + $expiryDate = $expiryDate.ToString("yyyy-MM-dd") + $webhookPayload = @{ + "data" = @{ + "Title" = "het certificaat van $($certificate.Name) ONT verloopt op $($expiryDate)" + "name" = $certificate.Name + "vaultName" = $KeyVaultName + "expiryDate" = $expiryDate + } + } + + $headers = @{ + "Content-Type" = "application/json" + "X-Automation-Webhook-Token" = $jiraWebhookSecret + } + + $jsonPayload = $webhookPayload | ConvertTo-Json + + Write-Host "Payload: $jsonPayload" + + try { + Invoke-RestMethod -Uri $jiraWebhookUrl -Method Post -Headers $headers -Body $jsonPayload + } catch { + Write-Host "Error: $_" + } + } + + Write-Output "Webhooks created for certificates expiring between 30 and 120 days." + azurePowerShellVersion: 'LatestVersion' + \ No newline at end of file From 2a74f69e11b702305fd515634a347c98e3d0c69f Mon Sep 17 00:00:00 2001 From: Abdellah Date: Wed, 4 Mar 2026 17:24:14 +0100 Subject: [PATCH 4/4] Deleted the test.yaml file --- test.yaml | 66 ------------------------------------------------------- 1 file changed, 66 deletions(-) delete mode 100644 test.yaml diff --git a/test.yaml b/test.yaml deleted file mode 100644 index cc36578..0000000 --- a/test.yaml +++ /dev/null @@ -1,66 +0,0 @@ - -- job: - displayName: 'jira webhook' - steps: - - checkout: self - - ${{ if eq(parameters.acc, true) }}: - - task: AzurePowerShell@5 - inputs: - azureSubscription: 'ARM-CCC-OPDR-ont-01' - ScriptType: 'InlineScript' - Inline: | - $resourceGroupName = 'shared-o-rg' - - $KeyVault = Get-AzResource -ResourceGroupName $resourceGroupName | Where-Object { - $_.ResourceType -eq "Microsoft.KeyVault/vaults" -and $_.Name -like "shared-o-*" - } - - $KeyVaultName = $KeyVault.Name - - $certificates = Get-AzKeyVaultCertificate -VaultName $KeyVaultName - - $currentDate = Get-Date - - $filteredCertificates = $certificates | Where-Object { - $_.Expires -gt $currentDate.AddDays(100) -and $_.Expires -lt $currentDate.AddDays(120) - } - - Write-Host "The certs to expire:" - $filteredCertificates - - Write-Host "Attempting Jira webhook:" - - $jiraWebhookUrl = 'https://api-private.atlassian.com/automation/webhooks/jira/a/f8771ef1-0a37-46ae-b72a-4f2586b482e2/01958f14-e3bc-7725-b7dd-f9a80dbf097b' - $jiraWebhookSecret = '57da1cd12db225cbe627ef2d6e4ad497ff54f1db' - - foreach ($certificate in $filteredCertificates) { - $expiryDate = Get-Date $certificate.Expires - $expiryDate = $expiryDate.ToString("yyyy-MM-dd") - $webhookPayload = @{ - "data" = @{ - "Title" = "het certificaat van $($certificate.Name) ONT verloopt op $($expiryDate)" - "name" = $certificate.Name - "vaultName" = $KeyVaultName - "expiryDate" = $expiryDate - } - } - - $headers = @{ - "Content-Type" = "application/json" - "X-Automation-Webhook-Token" = $jiraWebhookSecret - } - - $jsonPayload = $webhookPayload | ConvertTo-Json - - Write-Host "Payload: $jsonPayload" - - try { - Invoke-RestMethod -Uri $jiraWebhookUrl -Method Post -Headers $headers -Body $jsonPayload - } catch { - Write-Host "Error: $_" - } - } - - Write-Output "Webhooks created for certificates expiring between 30 and 120 days." - azurePowerShellVersion: 'LatestVersion' - \ No newline at end of file