Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

transition from terraform/terraspace to pulumi #9

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 0 additions & 3 deletions .env.dist

This file was deleted.

43 changes: 43 additions & 0 deletions .github/AUTORELEASE.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,43 @@
# Autorelease action

## Overview
Auto-release workflows automate the process of creating software releases in response to specific triggers like merging a pull request or pushing to a certain branch. This automation helps streamline the development process, reduce human error, and ensure consistent release practices.

---
## Why You Might Need Auto-Release
Consistency: Automating the release process ensures that every release adheres to predefined standards and procedures, reducing the risk of human error and inconsistency in the release quality.

Efficiency: By automating the changelog generation and release process, teams can save time and focus on development and testing rather than on the operational details of creating a release.

Integration: Auto-release workflows can be integrated with other tools and workflows, such as continuous integration (CI) systems, to ensure that releases are made only when all tests pass, maintaining the quality of the code in the production.

Traceability: Automated releases include detailed logs and changelogs, providing a clear audit trail for changes, which is beneficial for debugging and understanding the project’s history.

Speed: Automation speeds up the process of releasing and deploying software, which is especially crucial in high-paced agile environments where multiple releases might occur in a single day.

Comment on lines +1 to +17
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick (assertive)

Enhance document formatting and readability.

The content is well-structured, but some formatting improvements would enhance readability.

Apply these changes:

 # Autorelease action

 ## Overview
+
 Auto-release workflows automate the process of creating software releases in response to specific triggers like merging a pull request or pushing to a certain branch. This automation helps streamline the development process, reduce human error, and ensure consistent release practices.

 ---
+
 ## Why You Might Need Auto-Release
+
 Consistency: Automating the release process ensures that every release adheres to predefined standards and procedures, reducing the risk of human error and inconsistency in the release quality.

 Efficiency: By automating the changelog generation and release process, teams can save time and focus on development and testing rather than on the operational details of creating a release.

 Integration: Auto-release workflows can be integrated with other tools and workflows, such as continuous integration (CI) systems, to ensure that releases are made only when all tests pass, maintaining the quality of the code in the production.

 Traceability: Automated releases include detailed logs and changelogs, providing a clear audit trail for changes, which is beneficial for debugging and understanding the project's history.

-Speed: Automation speeds up the process of releasing and deploying software, which is especially crucial in high-paced agile environments where multiple releases might occur in a single day.
+Speed: Automation accelerates the process of releasing and deploying software, which is especially crucial in high-paced agile environments where multiple releases might occur in a single day.
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
# Autorelease action
## Overview
Auto-release workflows automate the process of creating software releases in response to specific triggers like merging a pull request or pushing to a certain branch. This automation helps streamline the development process, reduce human error, and ensure consistent release practices.
---
## Why You Might Need Auto-Release
Consistency: Automating the release process ensures that every release adheres to predefined standards and procedures, reducing the risk of human error and inconsistency in the release quality.
Efficiency: By automating the changelog generation and release process, teams can save time and focus on development and testing rather than on the operational details of creating a release.
Integration: Auto-release workflows can be integrated with other tools and workflows, such as continuous integration (CI) systems, to ensure that releases are made only when all tests pass, maintaining the quality of the code in the production.
Traceability: Automated releases include detailed logs and changelogs, providing a clear audit trail for changes, which is beneficial for debugging and understanding the project’s history.
Speed: Automation speeds up the process of releasing and deploying software, which is especially crucial in high-paced agile environments where multiple releases might occur in a single day.
# Autorelease action
## Overview
Auto-release workflows automate the process of creating software releases in response to specific triggers like merging a pull request or pushing to a certain branch. This automation helps streamline the development process, reduce human error, and ensure consistent release practices.
---
## Why You Might Need Auto-Release
Consistency: Automating the release process ensures that every release adheres to predefined standards and procedures, reducing the risk of human error and inconsistency in the release quality.
Efficiency: By automating the changelog generation and release process, teams can save time and focus on development and testing rather than on the operational details of creating a release.
Integration: Auto-release workflows can be integrated with other tools and workflows, such as continuous integration (CI) systems, to ensure that releases are made only when all tests pass, maintaining the quality of the code in the production.
Traceability: Automated releases include detailed logs and changelogs, providing a clear audit trail for changes, which is beneficial for debugging and understanding the project's history.
Speed: Automation accelerates the process of releasing and deploying software, which is especially crucial in high-paced agile environments where multiple releases might occur in a single day.
🧰 Tools
🪛 LanguageTool

[style] ~16-~16: Consider using a different verb to strengthen your wording.
Context: ...e project’s history. Speed: Automation speeds up the process of releasing and deploying ...

(SPEED_UP_ACCELERATE)

🪛 Markdownlint

3-3: Expected: 1; Actual: 0; Below
Headings should be surrounded by blank lines

(MD022, blanks-around-headings)


7-7: Expected: 1; Actual: 0; Above
Headings should be surrounded by blank lines

(MD022, blanks-around-headings)


7-7: Expected: 1; Actual: 0; Below
Headings should be surrounded by blank lines

(MD022, blanks-around-headings)

---
## Setting Up an Auto-Release Workflow
### Step-by-Step Guide
#### 1) The GitHub App configuration

Let's start by creating and configuring a GitHub App. Go to Settings > Developer Settings > GitHub Apps (Developer Settings is at the bottom of the Settings page). Click on New GitHub App.

Once you are creating a new GitHub app, make sure to configure the following:

Complete the necessary details for the application.
Uncheck the active webhook.
From the Repository Permissions, set the following:
Administration to Read and Write.
Contents to Read and Write.
Issues to Read and Write.
Metadata to Read Only.
Pull Requests to Read and Write.
Check Install Only on this account.
Comment on lines +25 to +35
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue

Enhance security-related instructions for GitHub App permissions.

While the permissions are correctly listed, it's important to emphasize security best practices.

Consider adding these security-focused improvements:

 Once you are creating a new GitHub app, make sure to configure the following:

-    Complete the necessary details for the application.
-    Uncheck the active webhook.
-    From the Repository Permissions, set the following:
-        Administration to Read and Write.
-        Contents to Read and Write.
-        Issues to Read and Write.
-        Metadata to Read Only.
-        Pull Requests to Read and Write.
-    Check Install Only on this account.
+    1. Complete the necessary details for the application:
+       - Set a clear, identifiable name (e.g., "YourOrg-AutoRelease")
+       - Provide a detailed description of the app's purpose
+    2. Uncheck the active webhook (not needed for this use case)
+    3. Configure Repository Permissions (principle of least privilege):
+       - Administration: Read & Write (required for branch protection)
+       - Contents: Read & Write (required for releases)
+       - Issues: Read & Write (required for release notes)
+       - Metadata: Read-only (minimum required)
+       - Pull Requests: Read & Write (required for automation)
+    4. For security: 
+       - Check "Install Only on this account"
+       - Enable "Suspend installations on detected abuse"
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
Once you are creating a new GitHub app, make sure to configure the following:
Complete the necessary details for the application.
Uncheck the active webhook.
From the Repository Permissions, set the following:
Administration to Read and Write.
Contents to Read and Write.
Issues to Read and Write.
Metadata to Read Only.
Pull Requests to Read and Write.
Check Install Only on this account.
Once you are creating a new GitHub app, make sure to configure the following:
1. Complete the necessary details for the application:
- Set a clear, identifiable name (e.g., "YourOrg-AutoRelease")
- Provide a detailed description of the app's purpose
2. Uncheck the active webhook (not needed for this use case)
3. Configure Repository Permissions (principle of least privilege):
- Administration: Read & Write (required for branch protection)
- Contents: Read & Write (required for releases)
- Issues: Read & Write (required for release notes)
- Metadata: Read-only (minimum required)
- Pull Requests: Read & Write (required for automation)
4. For security:
- Check "Install Only on this account"
- Enable "Suspend installations on detected abuse"
🧰 Tools
🪛 LanguageTool

[uncategorized] ~25-~25: This verb may not be in the correct tense. Consider changing the tense to fit the context better.
Context: ...ge). Click on New GitHub App. Once you are creating a new GitHub app, make sure to configur...

(AI_EN_LECTOR_REPLACEMENT_VERB_TENSE)

Once you have created the app, you need to install it on the repository you want to use it. Follow GitHub's guide on installing your apps to repositories you own.
One more thing you need to do from the app's settings. Go to the app's settings and generate a new private key. Copy that private key to a safe place and then copy the app ID. You will need both values as repository secrets.
You can easily find ID here(Settings > Application > configure your github APP > app settings > you can see app id)
Comment on lines +36 to +38
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue

Improve private key handling instructions.

The current instructions for private key handling could be more secure and detailed.

Add these security-focused improvements:

-Once you have created the app, you need to install it on the repository you want to use it. Follow GitHub's guide on installing your apps to repositories you own.
-One more thing you need to do from the app's settings. Go to the app's settings and generate a new private key. Copy that private key to a safe place and then copy the app ID. You will need both values as repository secrets.
-You can easily find ID here(Settings > Application > configure your github APP > app settings > you can see app id)
+After creating the app:
+1. Install the app on your repository:
+   - Go to the app's settings page
+   - Click "Install App"
+   - Select the repository where you want to use auto-release
+
+2. Generate and secure the private key:
+   - In app settings, click "Generate Private Key"
+   - The key will be automatically downloaded
+   - IMPORTANT: Store this key securely - it cannot be downloaded again
+   - If the key is ever compromised, revoke it immediately and generate a new one
+
+3. Locate the App ID:
+   - Find it at: Settings > Developer Settings > GitHub Apps > Your App > General
+   - The App ID is displayed at the top of the page
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
Once you have created the app, you need to install it on the repository you want to use it. Follow GitHub's guide on installing your apps to repositories you own.
One more thing you need to do from the app's settings. Go to the app's settings and generate a new private key. Copy that private key to a safe place and then copy the app ID. You will need both values as repository secrets.
You can easily find ID here(Settings > Application > configure your github APP > app settings > you can see app id)
After creating the app:
1. Install the app on your repository:
- Go to the app's settings page
- Click "Install App"
- Select the repository where you want to use auto-release
2. Generate and secure the private key:
- In app settings, click "Generate Private Key"
- The key will be automatically downloaded
- IMPORTANT: Store this key securely - it cannot be downloaded again
- If the key is ever compromised, revoke it immediately and generate a new one
3. Locate the App ID:
- Find it at: Settings > Developer Settings > GitHub Apps > Your App > General
- The App ID is displayed at the top of the page
🧰 Tools
🪛 LanguageTool

[uncategorized] ~37-~37: Possible missing comma found.
Context: ...te key. Copy that private key to a safe place and then copy the app ID. You will need...

(AI_HYDRA_LEO_MISSING_COMMA)


[uncategorized] ~38-~38: You might be missing the article “the” here.
Context: ...repository secrets. You can easily find ID here(Settings > Application > configure...

(AI_EN_LECTOR_MISSING_DETERMINER_THE)

#### 2) The GitHub repository configuration
Go to Settings > Secrets and Variables > Actions to create new secrets. Add one secret for the private key(VILNACRM_APP_PRIVATE_KEY) and another for the app ID(VILNACRM_APP_ID).
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Update secret naming convention.

The secret names should follow the repository's new infrastructure setup.

Since we're transitioning from Terraform to Pulumi, consider updating the secret names to match the new infrastructure naming convention:

-Go to Settings > Secrets and Variables > Actions to create new secrets. Add one secret for the private key(VILNACRM_APP_PRIVATE_KEY) and another for the app ID(VILNACRM_APP_ID).
+Go to Settings > Secrets and Variables > Actions to create new secrets:
+1. Add the private key as `PULUMI_AUTORELEASE_APP_KEY`
+2. Add the app ID as `PULUMI_AUTORELEASE_APP_ID`
+
+Note: These secrets will be used in the Pulumi-based deployment workflows.
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
Go to Settings > Secrets and Variables > Actions to create new secrets. Add one secret for the private key(VILNACRM_APP_PRIVATE_KEY) and another for the app ID(VILNACRM_APP_ID).
Go to Settings > Secrets and Variables > Actions to create new secrets:
1. Add the private key as `PULUMI_AUTORELEASE_APP_KEY`
2. Add the app ID as `PULUMI_AUTORELEASE_APP_ID`
Note: These secrets will be used in the Pulumi-based deployment workflows.

#### 3) Allow force push
To configure the repository branch protection rules, go to Settings > Branches.
Check the option to Allow force pushes and specify that the only allowed actor is the GitHub app you already installed.
Comment on lines +41 to +43
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue

Add caution notice for force push configuration.

The force push instructions need more context about potential risks.

Add these important warnings:

 #### 3) Allow force push
-To configure the repository branch protection rules, go to Settings > Branches.
-Check the option to Allow force pushes and specify that the only allowed actor is the GitHub app you already installed.
+
+CAUTION: Force push can overwrite repository history. Configure carefully:
+
+1. Go to Settings > Branches > Branch protection rules
+2. For the protected branch (e.g., main):
+   - Enable "Allow force pushes"
+   - IMPORTANT: Restrict force pushes to the GitHub App only
+   - Do NOT allow force pushes for other users or apps
+
+NOTE: Force push is required for the auto-release workflow to update version tags,
+but should be strictly limited to the GitHub App to prevent accidental history rewrites.
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
#### 3) Allow force push
To configure the repository branch protection rules, go to Settings > Branches.
Check the option to Allow force pushes and specify that the only allowed actor is the GitHub app you already installed.
#### 3) Allow force push
CAUTION: Force push can overwrite repository history. Configure carefully:
1. Go to Settings > Branches > Branch protection rules
2. For the protected branch (e.g., main):
- Enable "Allow force pushes"
- IMPORTANT: Restrict force pushes to the GitHub App only
- Do NOT allow force pushes for other users or apps
NOTE: Force push is required for the auto-release workflow to update version tags,
but should be strictly limited to the GitHub App to prevent accidental history rewrites.
🧰 Tools
🪛 Markdownlint

41-41: Expected: 1; Actual: 0; Above
Headings should be surrounded by blank lines

(MD022, blanks-around-headings)


41-41: Expected: 1; Actual: 0; Below
Headings should be surrounded by blank lines

(MD022, blanks-around-headings)


43-43: null
Files should end with a single newline character

(MD047, single-trailing-newline)

58 changes: 58 additions & 0 deletions .github/TEMPLATE_SYNC_APP.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,58 @@
# Template synchronization with GitHub App

Alternatively, you can configure a GitHub App to handle workflow permissions. This method offers a more integrated and secure approach compared to using a Personal Access Token (PAT).

For a detailed guide on how to set up a GitHub App and configure the necessary permissions, refer to the **[Autorelease action documentation](https://github.com/VilnaCRM-Org/php-service-template/blob/main/.github/AUTORELEASE.md)**.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick (assertive)

Update documentation reference to be more specific.

The current reference points to autorelease documentation, which may confuse users looking for GitHub App setup instructions. Consider creating a dedicated guide for GitHub App setup or updating the reference to point to GitHub's official documentation about creating GitHub Apps.

-For a detailed guide on how to set up a GitHub App and configure the necessary permissions, refer to the **[Autorelease action documentation](https://github.com/VilnaCRM-Org/php-service-template/blob/main/.github/AUTORELEASE.md)**.
+For a detailed guide on how to set up a GitHub App and configure the necessary permissions, refer to the **[GitHub Apps documentation](https://docs.github.com/en/apps/creating-github-apps/creating-github-apps/creating-a-github-app)**.
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
For a detailed guide on how to set up a GitHub App and configure the necessary permissions, refer to the **[Autorelease action documentation](https://github.com/VilnaCRM-Org/php-service-template/blob/main/.github/AUTORELEASE.md)**.
For a detailed guide on how to set up a GitHub App and configure the necessary permissions, refer to the **[GitHub Apps documentation](https://docs.github.com/en/apps/creating-github-apps/creating-github-apps/creating-a-github-app)**.


## Overview

By configuring a GitHub App, you can automate repository synchronization while ensuring secure handling of repository permissions without manual token management.

### Steps Overview

1. **GitHub App Configuration**:
- Create and configure the GitHub App with the required permissions (`Administration`, `Contents`, `Issues`, `Metadata`, and `Pull Requests`).

2. **Repository Secrets**:
- Configure secrets for the private key and App ID.

3. **Branch Protection Rules**:
- Set branch protection rules to allow force pushing by the GitHub App.
Comment on lines +13 to +20
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick (assertive)

Enhance setup instructions with specific permission scopes.

While the steps are clear, adding more specific details would help users avoid common setup issues:

 1. **GitHub App Configuration**:
-    -  Create and configure the GitHub App with the required permissions (`Administration`, `Contents`, `Issues`, `Metadata`, and `Pull Requests`).
+    - Create and configure the GitHub App with the following specific permissions:
+      - Repository Administration: Read & Write (for managing repository settings)
+      - Repository Contents: Read & Write (for creating PRs and commits)
+      - Issues: Read & Write (for creating linked issues if needed)
+      - Metadata: Read-only (minimum required permission)
+      - Pull Requests: Read & Write (for creating and managing sync PRs)
 
 3. **Branch Protection Rules**:
-    - Set branch protection rules to allow force pushing by the GitHub App.
+    - Navigate to repository Settings > Branches > Branch protection rules
+    - Add the GitHub App to the list of accounts allowed to bypass branch protections
+    - Ensure "Allow force pushes" is enabled for the GitHub App
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
1. **GitHub App Configuration**:
- Create and configure the GitHub App with the required permissions (`Administration`, `Contents`, `Issues`, `Metadata`, and `Pull Requests`).
2. **Repository Secrets**:
- Configure secrets for the private key and App ID.
3. **Branch Protection Rules**:
- Set branch protection rules to allow force pushing by the GitHub App.
1. **GitHub App Configuration**:
- Create and configure the GitHub App with the following specific permissions:
- Repository Administration: Read & Write (for managing repository settings)
- Repository Contents: Read & Write (for creating PRs and commits)
- Issues: Read & Write (for creating linked issues if needed)
- Metadata: Read-only (minimum required permission)
- Pull Requests: Read & Write (for creating and managing sync PRs)
2. **Repository Secrets**:
- Configure secrets for the private key and App ID.
3. **Branch Protection Rules**:
- Navigate to repository Settings > Branches > Branch protection rules
- Add the GitHub App to the list of accounts allowed to bypass branch protections
- Ensure "Allow force pushes" is enabled for the GitHub App


### GitHub Action Configuration

Below is an example of a GitHub action using the GitHub App for repository synchronization:

```yaml
name: Template Sync

on:
schedule:
- cron: "0 9 * * MON"
workflow_dispatch:

jobs:
repo-sync:
runs-on: ubuntu-latest

steps:
- name: Generate token to read from source repo
id: generate_token
uses: tibdex/github-app-token@v2
with:
app_id: ${{ secrets.<GITHUB_APP_ID> }}
private_key: ${{ secrets.<GITHUB_APP_PRIVATE_KEY> }}

- name: Checkout
uses: actions/checkout@v4
with:
token: ${{ steps.generate_token.outputs.token }}

- name: actions-template-sync
uses: AndreasAugustin/actions-template-sync@v2
with:
github_token: ${{ steps.generate_token.outputs.token }}
source_repo_path: <owner/repo>
upstream_branch: <target_branch> # defaults to main
pr_labels: <label1>,<label2>[,...] # optional, no default
```
Comment on lines +26 to +58
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Add security considerations and best practices to the workflow example.

The workflow configuration is functional but could benefit from additional security measures and best practices:

 name: Template Sync

 on:
   schedule:
     - cron: "0 9 * * MON"
   workflow_dispatch:

+permissions:
+  contents: write
+  pull-requests: write

 jobs:
   repo-sync:
     runs-on: ubuntu-latest
+    # Prevent concurrent syncs
+    concurrency:
+      group: template-sync
+      cancel-in-progress: true

     steps:
       - name: Generate token to read from source repo
         id: generate_token
         uses: tibdex/github-app-token@v2
         with:
-          app_id: ${{ secrets.<GITHUB_APP_ID> }}
-          private_key: ${{ secrets.<GITHUB_APP_PRIVATE_KEY> }}
+          app_id: ${{ secrets.TEMPLATE_SYNC_APP_ID }}
+          private_key: ${{ secrets.TEMPLATE_SYNC_PRIVATE_KEY }}

       - name: Checkout
         uses: actions/checkout@v4
         with:
           token: ${{ steps.generate_token.outputs.token }}
+          fetch-depth: 0  # Required for template sync

       - name: actions-template-sync
         uses: AndreasAugustin/actions-template-sync@v2
         with:
           github_token: ${{ steps.generate_token.outputs.token }}
-          source_repo_path: <owner/repo>
-          upstream_branch: <target_branch> # defaults to main
-          pr_labels: <label1>,<label2>[,...] # optional, no default
+          source_repo_path: VilnaCRM-Org/infrastructure-template
+          upstream_branch: main
+          pr_labels: automated,template-sync
+          pr_title: "chore: sync with template repository"

Also, consider adding error handling and notifications:

      - name: Notify on failure
        if: failure()
        uses: actions/github-script@v7
        with:
          script: |
            github.rest.issues.create({
              owner: context.repo.owner,
              repo: context.repo.repo,
              title: 'Template sync failed',
              body: 'The template sync workflow failed. Please check the workflow logs.'
            })
🧰 Tools
🪛 Markdownlint

58-58: null
Files should end with a single newline character

(MD047, single-trailing-newline)

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick (assertive)

Add missing newline at end of file.

Add a newline character at the end of the file to comply with standard file formatting practices.

🧰 Tools
🪛 Markdownlint

58-58: null
Files should end with a single newline character

(MD047, single-trailing-newline)

56 changes: 56 additions & 0 deletions .github/TEMPLATE_SYNC_PAT.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,56 @@
# Template synchronization with a Personal Access Token (PAT)

Currently, the `GITHUB_TOKEN` cannot be granted workflow permissions by default. You can grant the workflow permissions using a Personal Access Token (PAT) by following these steps:

1. [Create a PAT](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-fine-grained-personal-access-token) with the following repository permissions:
- `contents:write`
- `workflows:write`
- `metadata:read`
Comment on lines +5 to +8
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick (assertive)

Consider limiting PAT scope for enhanced security

While the listed permissions are correct, consider mentioning that the PAT should be:

  1. Limited to specific repositories rather than all repositories
  2. Set with an appropriate expiration date
  3. Regularly rotated as per security best practices


To make the options for repository permissions (such as contents:write, workflows:write, and metadata:read) appear, ensure that the access level is not set to read-only.

2. Copy the generated token and [create a new secret](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#creating-secrets-for-a-repository) for your target repository.

3. Configure the checkout action to use the token in secrets, as shown below:

```yaml
# File: .github/workflows/template-sync-app.yml
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue

Fix incorrect filename in the example

The filename in the comment shows template-sync-app.yml but based on the context, it should be template-sync-pat.yml.

-# File: .github/workflows/template-sync-app.yml
+# File: .github/workflows/template-sync-pat.yml
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
# File: .github/workflows/template-sync-app.yml
# File: .github/workflows/template-sync-pat.yml


on:
# cronjob trigger
schedule:
- cron: "0 0 1 * *"
# manual trigger
workflow_dispatch:

jobs:
repo-sync:
runs-on: ubuntu-latest
# https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs
permissions:
contents: write
pull-requests: write

steps:
# To use this repository's private action, you must check out the repository
- name: Checkout
uses: actions/checkout@v4
with:
# submodules: true
token: ${{ secrets.<secret_name> }}
Comment on lines +39 to +40
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick (assertive)

Clarify submodules configuration

The commented submodules: true line needs explanation. Consider either:

  1. Removing it if not needed
  2. Adding a comment explaining when users should uncomment it


- name: actions-template-sync
uses: AndreasAugustin/actions-template-sync@v2
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
source_repo_path: <owner/repo>
upstream_branch: <target_branch> # defaults to main
pr_labels: <label1>,<label2>[,...] # optional, no default
Comment on lines +46 to +48
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick (assertive)

Add examples for placeholder values

The placeholders need more context. Consider adding comments:

-              source_repo_path: <owner/repo>
-              upstream_branch: <target_branch> # defaults to main
-              pr_labels: <label1>,<label2>[,...] # optional, no default
+              source_repo_path: <owner/repo> # e.g., "VilnaCRM-Org/infrastructure-template"
+              upstream_branch: <target_branch> # defaults to main, e.g., "master"
+              pr_labels: <label1>,<label2>[,...] # optional, e.g., "sync,automated"
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
source_repo_path: <owner/repo>
upstream_branch: <target_branch> # defaults to main
pr_labels: <label1>,<label2>[,...] # optional, no default
source_repo_path: <owner/repo> # e.g., "VilnaCRM-Org/infrastructure-template"
upstream_branch: <target_branch> # defaults to main, e.g., "master"
pr_labels: <label1>,<label2>[,...] # optional, e.g., "sync,automated"

```

4. If you encounter the error `pull request create failed: Actions is not permitted to create or approve pull requests (createPullRequest)`, follow these additional steps:

- Go to your project’s **Settings** > **Actions** > **General**.
- Under the **Workflow permissions** section, check the box for **Allow GitHub Actions to create and approve pull requests**.
Comment on lines +53 to +54
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick (assertive)

Add security warning for workflow permissions

Consider adding a security note about the implications of allowing GitHub Actions to create and approve PRs, as this could potentially be exploited if a workflow is compromised.

    - Go to your project's **Settings** > **Actions** > **General**.
    - Under the **Workflow permissions** section, check the box for **Allow GitHub Actions to create and approve pull requests**.
+    > **Security Note**: Enabling this permission allows any workflow in the repository to create and approve pull requests. Ensure all workflows are properly secured and reviewed.
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
- Go to your project’s **Settings** > **Actions** > **General**.
- Under the **Workflow permissions** section, check the box for **Allow GitHub Actions to create and approve pull requests**.
- Go to your project's **Settings** > **Actions** > **General**.
- Under the **Workflow permissions** section, check the box for **Allow GitHub Actions to create and approve pull requests**.
> **Security Note**: Enabling this permission allows any workflow in the repository to create and approve pull requests. Ensure all workflows are properly secured and reviewed.


Following these steps should resolve any permission issues with workflows, allowing smooth synchronization between repositories.
Comment on lines +1 to +56
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick (assertive)

Fix markdown formatting issues

Please address the following formatting issues:

  1. Ensure consistent ordered list numbering style (currently mixing styles)
  2. Add a trailing newline at the end of the file
 Following these steps should resolve any permission issues with workflows, allowing smooth synchronization between repositories.
+
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
# Template synchronization with a Personal Access Token (PAT)
Currently, the `GITHUB_TOKEN` cannot be granted workflow permissions by default. You can grant the workflow permissions using a Personal Access Token (PAT) by following these steps:
1. [Create a PAT](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-fine-grained-personal-access-token) with the following repository permissions:
- `contents:write`
- `workflows:write`
- `metadata:read`
To make the options for repository permissions (such as contents:write, workflows:write, and metadata:read) appear, ensure that the access level is not set to read-only.
2. Copy the generated token and [create a new secret](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#creating-secrets-for-a-repository) for your target repository.
3. Configure the checkout action to use the token in secrets, as shown below:
```yaml
# File: .github/workflows/template-sync-app.yml
on:
# cronjob trigger
schedule:
- cron: "0 0 1 * *"
# manual trigger
workflow_dispatch:
jobs:
repo-sync:
runs-on: ubuntu-latest
# https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs
permissions:
contents: write
pull-requests: write
steps:
# To use this repository's private action, you must check out the repository
- name: Checkout
uses: actions/checkout@v4
with:
# submodules: true
token: ${{ secrets.<secret_name> }}
- name: actions-template-sync
uses: AndreasAugustin/actions-template-sync@v2
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
source_repo_path: <owner/repo>
upstream_branch: <target_branch> # defaults to main
pr_labels: <label1>,<label2>[,...] # optional, no default
```
4. If you encounter the error `pull request create failed: Actions is not permitted to create or approve pull requests (createPullRequest)`, follow these additional steps:
- Go to your project’s **Settings** > **Actions** > **General**.
- Under the **Workflow permissions** section, check the box for **Allow GitHub Actions to create and approve pull requests**.
Following these steps should resolve any permission issues with workflows, allowing smooth synchronization between repositories.
# Template synchronization with a Personal Access Token (PAT)
Currently, the `GITHUB_TOKEN` cannot be granted workflow permissions by default. You can grant the workflow permissions using a Personal Access Token (PAT) by following these steps:
1. [Create a PAT](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-fine-grained-personal-access-token) with the following repository permissions:
- `contents:write`
- `workflows:write`
- `metadata:read`
To make the options for repository permissions (such as contents:write, workflows:write, and metadata:read) appear, ensure that the access level is not set to read-only.
2. Copy the generated token and [create a new secret](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#creating-secrets-for-a-repository) for your target repository.
3. Configure the checkout action to use the token in secrets, as shown below:
```yaml
# File: .github/workflows/template-sync-app.yml
on:
# cronjob trigger
schedule:
- cron: "0 0 1 * *"
# manual trigger
workflow_dispatch:
jobs:
repo-sync:
runs-on: ubuntu-latest
# https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs
permissions:
contents: write
pull-requests: write
steps:
# To use this repository's private action, you must check out the repository
- name: Checkout
uses: actions/checkout@v4
with:
# submodules: true
token: ${{ secrets.<secret_name> }}
- name: actions-template-sync
uses: AndreasAugustin/actions-template-sync@v2
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
source_repo_path: <owner/repo>
upstream_branch: <target_branch> # defaults to main
pr_labels: <label1>,<label2>[,...] # optional, no default
```
4. If you encounter the error `pull request create failed: Actions is not permitted to create or approve pull requests (createPullRequest)`, follow these additional steps:
- Go to your project's **Settings** > **Actions** > **General**.
- Under the **Workflow permissions** section, check the box for **Allow GitHub Actions to create and approve pull requests**.
Following these steps should resolve any permission issues with workflows, allowing smooth synchronization between repositories.
🧰 Tools
🪛 Markdownlint

12-12: Expected: 1; Actual: 2; Style: 1/2/3
Ordered list item prefix

(MD029, ol-prefix)


14-14: Expected: 2; Actual: 3; Style: 1/2/3
Ordered list item prefix

(MD029, ol-prefix)


51-51: Expected: 3; Actual: 4; Style: 1/2/3
Ordered list item prefix

(MD029, ol-prefix)


56-56: null
Files should end with a single newline character

(MD047, single-trailing-newline)

6 changes: 6 additions & 0 deletions .github/dependabot.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,6 @@
version: 2
updates:
- package-ecosystem: "pip"
directory: "pulumi"
schedule:
interval: "weekly"
Comment on lines +1 to +6
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick (assertive)

Enhance Dependabot configuration for better PR management.

While the basic configuration is functional, consider adding these options to improve the PR workflow:

 version: 2
 updates:
   - package-ecosystem: "pip"
     directory: "pulumi"
     schedule:
       interval: "weekly"
+    commit-message:
+      prefix: "deps(pulumi)"
+      include: "scope"
+    labels:
+      - "dependencies"
+      - "pulumi"
+    reviewers:
+      - "Kravalg"
+    versioning-strategy: increase-if-necessary
+    open-pull-requests-limit: 5

Also, add a newline at the end of the file to fix the YAML linting error.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
version: 2
updates:
- package-ecosystem: "pip"
directory: "pulumi"
schedule:
interval: "weekly"
version: 2
updates:
- package-ecosystem: "pip"
directory: "pulumi"
schedule:
interval: "weekly"
commit-message:
prefix: "deps(pulumi)"
include: "scope"
labels:
- "dependencies"
- "pulumi"
reviewers:
- "Kravalg"
versioning-strategy: increase-if-necessary
open-pull-requests-limit: 5
🧰 Tools
🪛 yamllint

[error] 6-6: no new line character at the end of file

(new-line-at-end-of-file)

34 changes: 34 additions & 0 deletions .github/linters/.yaml-lint.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,34 @@
extends: default

rules:
document-start: disable

indentation:
spaces: 2
level: error # Enforce strict indentation
Comment on lines +6 to +8
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick (assertive)

Fix comment spacing while maintaining good indentation rules.

The indentation configuration is appropriate, using the standard 2-space format with strict enforcement.

Fix the comment spacing:

  indentation:
    spaces: 2
-    level: error # Enforce strict indentation
+    level: error  # Enforce strict indentation
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
indentation:
spaces: 2
level: error # Enforce strict indentation
indentation:
spaces: 2
level: error # Enforce strict indentation
🧰 Tools
🪛 yamllint

[warning] 8-8: too few spaces before comment

(comments)


line-length:
max: 120
level: warning # Consider changing this to 100 for better readability
Comment on lines +10 to +12
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick (assertive)

Consider reducing maximum line length for better readability.

The current 120-character limit is quite permissive. Consider reducing it to 100 characters as suggested in the comment, which is more standard for YAML files and improves readability, especially in side-by-side views and code reviews.

  line-length:
-    max: 120
-    level: warning # Consider changing this to 100 for better readability
+    max: 100
+    level: warning  # Standard line length for better readability
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
line-length:
max: 120
level: warning # Consider changing this to 100 for better readability
line-length:
max: 100
level: warning # Standard line length for better readability
🧰 Tools
🪛 yamllint

[warning] 12-12: too few spaces before comment

(comments)


new-line-at-end-of-file:
level: warning

trailing-spaces:
level: error # Enforce no trailing spaces
Comment on lines +14 to +18
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Strengthen new-line-at-end-of-file rule enforcement.

While the trailing spaces rule is correctly set to error level, consider elevating the new-line-at-end-of-file rule to error level as well. This is a widely accepted best practice that helps prevent issues with text processing tools and version control systems.

  new-line-at-end-of-file:
-    level: warning
+    level: error
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
new-line-at-end-of-file:
level: warning
trailing-spaces:
level: error # Enforce no trailing spaces
new-line-at-end-of-file:
level: error
trailing-spaces:
level: error # Enforce no trailing spaces
🧰 Tools
🪛 yamllint

[warning] 18-18: too few spaces before comment

(comments)


brackets:
level: error # Enforce proper bracket usage

commas:
level: error # Enforce proper comma usage

braces:
level: error # Enforce proper brace usage

empty-lines:
max: 1 # Allow at least one empty line for readability
level: warning

colons:
level: error # Enforce proper colon usage
Comment on lines +1 to +34
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick (assertive)

Consider extending linting coverage for Pulumi-specific files.

Since this PR transitions from Terraform to Pulumi, consider adding specific linting rules or configurations for Pulumi files (typically TypeScript/JavaScript/Python) to ensure consistent code quality across all infrastructure code.

Would you like assistance in setting up additional linting configurations for Pulumi files?

🧰 Tools
🪛 yamllint

[warning] 8-8: too few spaces before comment

(comments)


[warning] 12-12: too few spaces before comment

(comments)


[warning] 18-18: too few spaces before comment

(comments)


[warning] 21-21: too few spaces before comment

(comments)


[warning] 24-24: too few spaces before comment

(comments)


[warning] 27-27: too few spaces before comment

(comments)


[warning] 30-30: too few spaces before comment

(comments)


[error] 34-34: no new line character at the end of file

(new-line-at-end-of-file)

Comment on lines +20 to +34
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue

Fix formatting issues while maintaining good syntax rules.

The syntax rules are well-configured with appropriate error levels. However, there are some formatting issues to address:

  1. Add a newline at the end of the file
  2. Fix comment spacing throughout the file

Apply these changes:

  brackets:
-    level: error # Enforce proper bracket usage
+    level: error  # Enforce proper bracket usage

  commas:
-    level: error # Enforce proper comma usage
+    level: error  # Enforce proper comma usage

  braces:
-    level: error # Enforce proper brace usage
+    level: error  # Enforce proper brace usage

  empty-lines:
-    max: 1 # Allow at least one empty line for readability
+    max: 1  # Allow at least one empty line for readability
    level: warning

  colons:
-    level: error # Enforce proper colon usage
+    level: error  # Enforce proper colon usage
+
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
brackets:
level: error # Enforce proper bracket usage
commas:
level: error # Enforce proper comma usage
braces:
level: error # Enforce proper brace usage
empty-lines:
max: 1 # Allow at least one empty line for readability
level: warning
colons:
level: error # Enforce proper colon usage
brackets:
level: error # Enforce proper bracket usage
commas:
level: error # Enforce proper comma usage
braces:
level: error # Enforce proper brace usage
empty-lines:
max: 1 # Allow at least one empty line for readability
level: warning
colons:
level: error # Enforce proper colon usage
🧰 Tools
🪛 yamllint

[warning] 21-21: too few spaces before comment

(comments)


[warning] 24-24: too few spaces before comment

(comments)


[warning] 27-27: too few spaces before comment

(comments)


[warning] 30-30: too few spaces before comment

(comments)


[error] 34-34: no new line character at the end of file

(new-line-at-end-of-file)

38 changes: 0 additions & 38 deletions .github/workflows/autoprerelase.yml

This file was deleted.

32 changes: 17 additions & 15 deletions .github/workflows/autorelease.yml
Original file line number Diff line number Diff line change
@@ -1,37 +1,39 @@
name: generate changelog and create release
name: Generate Changelog and Create Release

on:
push:
branches: [ "main" ]
paths-ignore:
- 'CHANGELOG.md'
branches:
- main

jobs:
build:
runs-on: ubuntu-latest

permissions:
contents: write

steps:
- name: Generate token
id: generate_token
uses: tibdex/github-app-token@v1
with:
app_id: ${{ secrets.VILNACRM_APP_ID }}
private_key: ${{ secrets.VILNACRM_APP_PRIVATE_KEY }}
- name: Checkout code
uses: actions/checkout@v4
uses: actions/checkout@v2
with:
ref: 'main'
token: ${{ steps.generate_token.outputs.token }}

Comment on lines +20 to +22
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue

Update checkout action to latest version.

The current version (v2) of actions/checkout is outdated and may have security vulnerabilities.

Apply this diff to update to the latest stable version:

-        uses: actions/checkout@v2
+        uses: actions/checkout@v4
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
uses: actions/checkout@v2
with:
ref: 'main'
token: ${{ steps.generate_token.outputs.token }}
uses: actions/checkout@v4
with:
token: ${{ steps.generate_token.outputs.token }}
🧰 Tools
🪛 actionlint

20-20: the runner of "actions/checkout@v2" action is too old to run on GitHub Actions. update the action's version to fix this issue

(action)

- name: Conventional Changelog Action
id: changelog
uses: TriPSs/conventional-changelog-action@v4
uses: TriPSs/conventional-changelog-action@v5
with:
github-token: ${{ secrets.REPO_GITHUB_TOKEN }}
output-file: 'CHANGELOG.md'

github-token: ${{ steps.generate_token.outputs.token }}
output-file: "CHANGELOG.md"
version-file: "pulumi/pyproject.toml"
- name: Create Release
Comment on lines +26 to +30
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codebase verification

Version file path needs to be updated in the autorelease workflow

The pulumi/pyproject.toml file exists but does not contain a version field. The autorelease workflow's conventional-changelog-action requires a version field to function properly. The path configuration needs to be corrected.

  • .github/workflows/autorelease.yml: Update the version-file parameter to point to a file that contains version information.
🔗 Analysis chain

Verify Pulumi version file path.

The changelog action is now configured to read version from pulumi/pyproject.toml. As part of the Terraform to Pulumi migration, we should verify this path.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the existence and structure of the Pulumi version file

# Check if the version file exists
if [ -f "pulumi/pyproject.toml" ]; then
    echo "✓ Version file exists"
    # Check if it contains version information
    grep -A 5 "version" pulumi/pyproject.toml
else
    echo "✗ Version file not found at pulumi/pyproject.toml"
    # List potential version files to help locate the correct path
    find . -name "pyproject.toml" -o -name "package.json" -o -name "VERSION"
fi

Length of output: 1031


Script:

#!/bin/bash
# Let's check the content of Pulumi configuration files and pyproject.toml
echo "Checking Pulumi.yaml files:"
cat ./pulumi/Pulumi.yaml
echo -e "\nChecking Pulumi.example.yaml:"
cat ./pulumi/Pulumi.example.yaml
echo -e "\nLooking for pyproject.toml:"
find . -name "pyproject.toml" -type f -exec cat {} \;

Length of output: 922

uses: actions/create-release@v1
if: ${{ steps.changelog.outputs.skipped == 'false' }}
env:
GITHUB_TOKEN: ${{ secrets.REPO_GITHUB_TOKEN }}
GITHUB_TOKEN: ${{ steps.generate_token.outputs.token }}
with:
tag_name: ${{ steps.changelog.outputs.tag }}
release_name: ${{ steps.changelog.outputs.tag }}
body: ${{ steps.changelog.outputs.clean_changelog }}
body: ${{ steps.changelog.outputs.clean_changelog }}
19 changes: 0 additions & 19 deletions .github/workflows/checkov.yml

This file was deleted.

54 changes: 0 additions & 54 deletions .github/workflows/infracost.yml

This file was deleted.

Loading
Loading