repos/infra-meraki-config
5
0
Fork 0
Code Issues Pull Requests 1 Actions Activity

Add actions #1

Merged
luke merged 1 commits from actions into main 2025-05-10 22:22:02 +00:00
Conversation 1 Commits 1 Files Changed 5 +137
luke commented 2025-05-10 22:13:12 +00:00
Owner
Copy Link

Okay, here's a breakdown of the code changes presented in the diff, formatted for clarity and suitable for posting to a pull request:

Overall Purpose

This pull request introduces Continuous Integration (CI) and Continuous Deployment (CD) workflows using Gitea Actions and OpenTofu (an open-source fork of Terraform). It also sets up Renovate Bot for dependency management and adds a code owner.

File-by-File Analysis

  1. .gitea/CODEOWNERS

    • New File: This file specifies code ownership.

    • Content:

      *   @luke

      This line indicates that user @luke is responsible for all files in the repository. This means @luke will be requested for review on all pull requests.

  2. .gitea/workflows/ci.yml

    • New File: Defines the CI workflow.

    • Purpose: This workflow is triggered on pull requests and performs the following actions:

    • Workflow Details:

      name: CI
on:
  pull_request:
    types:
      - opened
      - edited
      - synchronize
      - reopened

jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - name: Check out repository
        uses: actions/checkout@v4.2.2

      - name: Setup OpenTofu
        uses: opentofu/setup-opentofu@v1

      - name: OpenTofu fmt
        id: fmt
        run: tofu fmt -check
        continue-on-error: true

      - name: OpenTofu init
        id: init
        run: tofu init

      - name: OpenTofu validate
        id: validate
        run: tofu validate -no-color

      - name: OpenTofu refresh
        id: validate
        run: tofu refresh
        continue-on-error: true

      - name: OpenTofu plan
        id: plan
        run: tofu plan -no-color
        continue-on-error: true

      - name: Post comment to PR
        if: gitea.event_name == 'pull_request'
        env:
          PLAN: "tofu\n${{ steps.plan.outputs.stdout }}"
        run: |
          export PR_NUMBER="${{ gitea.event.number }}"
          sed -i "s+[FMT_OUTCOME]+${{ steps.fmt.outcome }}+g" pr_comment.md
          sed -i "s+[INIT_OUTCOME]+${{ steps.init.outcome }}+g" pr_comment.md
          sed -i "s+[VALIDATE_OUTCOME]+${{ steps.validate.outcome }}+g" pr_comment.md
          sed -i "s+[VALIDATE_OUTPUT]+${{ steps.validate.outputs.stdout }}+g" pr_comment.md
          sed -i "s+[PLAN_OUTCOME]+${{ steps.plan.outcome }}+g" pr_comment.md
          curl -X POST \
            -H "Authorization: token ${{ secrets.ACTIONS_TOKEN }}" \
            -H "Content-Type: application/json" \
            -d "{\"body\": \"$(cat pr_comment.md)\"}" \
            "https://${{ gitea.server_url }}/api/v1/repos/${{ gitea.repository }}/issues/$PR_NUMBER/comments"
      • Checkout: Checks out the code.
      • Setup OpenTofu: Installs OpenTofu.
      • tofu fmt -check: Checks if the OpenTofu code is properly formatted. continue-on-error: true means the workflow won't fail if formatting is incorrect, but the result will be reported.
      • tofu init: Initializes the OpenTofu environment (downloads providers, etc.).
      • tofu validate: Validates the OpenTofu configuration. -no-color disables color output for easier parsing.
      • tofu refresh: Refreshes the state.
      • tofu plan: Generates an execution plan. continue-on-error: true means the workflow won't fail if the plan has errors, but the result will be reported.
      • Post comment to PR: This step posts a comment to the pull request with the results of the OpenTofu checks. It uses sed to replace placeholders in pr_comment.md with the outcomes and outputs of the previous steps. It then uses curl to make an API request to Gitea to create the comment. This requires the ACTIONS_TOKEN secret to be set up in the Gitea repository settings.

  3. .gitea/workflows/deploy.yml

    • New File: Defines the CD (deployment) workflow.

    • Purpose: This workflow is triggered on pushes to the main branch within the tf/** path, deploying the OpenTofu configuration.

    • Workflow Details:

      name: Deploy
on:
  push:
    branches:
      - main
    paths:
    - tf/**

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Check out repository
        uses: actions/checkout@v4.2.2

      - name: Setup OpenTofu
        uses: opentofu/setup-opentofu@v1

      - name: OpenTofu init
        id: init
        run: tofu init

      - name: OpenTofu validate
        id: validate
        run: tofu validate -no-color

      - name: OpenTofu refresh
        id: validate
        run: tofu refresh

      - name: OpenTofu plan
        id: plan
        run: tofu plan -no-color -out /tmp/plan.tfplan

      - name: OpenTofu apply
        id: apply
        run: tofu apply /tmp/plan.tfplan
      • Checkout: Checks out the code.
      • Setup OpenTofu: Installs OpenTofu.
      • tofu init: Initializes the OpenTofu environment.
      • tofu validate: Validates the OpenTofu configuration.
      • tofu refresh: Refreshes the state.
      • tofu plan: Generates an execution plan and saves it to /tmp/plan.tfplan.
      • tofu apply: Applies the OpenTofu configuration using the saved plan.

  4. pr_comment.md

    • New File: This file contains the Markdown template used for the pull request comment generated by the CI workflow.

    • Content:

      #### OpenTofu Format and Style 🖌  [FMT_OUTCOME]
#### OpenTofu Initialization ⚙️ [INIT_OUTCOME]
#### OpenTofu Validation 🤖 [VALIDATE_OUTCOME]

<details><summary>Validation Output</summary>

\`\`\`\n
[VALIDATE_OUTPUT]
\`\`\`

</details>

#### OpenTofu Plan 📖 [PLAN_OUTCOME]

<details><summary>Show Plan</summary>

\`\`\`\n
[PLAN_OUTPUT]
\`\`\`

</details>

      This template uses placeholders (e.g., [FMT_OUTCOME], [VALIDATE_OUTPUT]) that are replaced by the CI workflow with the actual results of the OpenTofu checks. The <details> tags create collapsible sections in the comment.

  5. renovate.json

    • New File: Configuration file for Renovate Bot, a tool that automatically creates pull requests to update dependencies.

    • Configuration:

      {
  "assignAutomerge": false,
  "assigneesFromCodeOwners": false,
  "dependencyDashboardAutoclose": true,
  "extends": ["config:recommended"],
  "ignorePaths": ["**/.archive/**"],
  "labels": ["type/dependencies"],
  "platformCommit": "enabled",
  "rebaseWhen": "behind-base-branch",
  "rollbackPrs": true,
  "vulnerabilityAlerts": {
    "commitMessagePrefix": "[SECURITY] ",
    "enabled": true,
    "labels": ["security"],
    "prCreation": "immediate"
  },
  "lockFileMaintenance": {
    "enabled": true
  }
}
      • extends: Inherits recommended settings.
      • ignorePaths: Ignores files in the .archive directory.
      • labels: Applies the type/dependencies label to dependency update PRs.
      • rebaseWhen: Rebases PRs when the base branch has advanced.
      • vulnerabilityAlerts: Enables vulnerability alerts, prefixes commit messages with "[SECURITY]", adds the "security" label, and creates PRs immediately.
      • lockFileMaintenance: Enables lock file maintenance (keeping dependency versions consistent).

Summary of Changes and Key Considerations

  • Automation: The CI/CD workflows automate the process of validating, planning, and applying OpenTofu configurations.
  • Feedback: The CI workflow provides feedback on pull requests by posting comments with the results of the OpenTofu checks.
  • Dependency Management: Renovate Bot automates dependency updates.
  • Code Ownership: The CODEOWNERS file assigns responsibility for the codebase.
  • Security: Vulnerability alerts are enabled for dependency updates.

Recommendations

  • Secrets Management: Ensure the ACTIONS_TOKEN secret is properly configured in the Gitea repository settings for the CI workflow to post comments.
  • Testing: Consider adding more comprehensive testing to the CI workflow (e.g., running integration tests).
  • Error Handling: Review the continue-on-error settings in the CI workflow to ensure that errors are handled appropriately. Consider if a failure should halt the process.
  • Permissions: Review the permissions granted to the ACTIONS_TOKEN to ensure they are minimal but sufficient for the workflow's needs.
  • State Management: For the deploy workflow, consider where your OpenTofu state is stored. Storing state locally on the runner will not work well. Consider using a remote backend.

This detailed explanation should provide a good understanding of the changes introduced by this pull request. Let me know if you have any other questions.

Okay, here's a breakdown of the code changes presented in the diff, formatted for clarity and suitable for posting to a pull request: **Overall Purpose** This pull request introduces Continuous Integration (CI) and Continuous Deployment (CD) workflows using Gitea Actions and OpenTofu (an open-source fork of Terraform). It also sets up Renovate Bot for dependency management and adds a code owner. **File-by-File Analysis** 1. **.gitea/CODEOWNERS** * **New File:** This file specifies code ownership. * **Content:** ``` * @luke ``` This line indicates that user `@luke` is responsible for all files in the repository. This means `@luke` will be requested for review on all pull requests. 2. **.gitea/workflows/ci.yml** * **New File:** Defines the CI workflow. * **Purpose:** This workflow is triggered on pull requests and performs the following actions: * **Workflow Details:** ```yaml name: CI on: pull_request: types: - opened - edited - synchronize - reopened jobs: ci: runs-on: ubuntu-latest steps: - name: Check out repository uses: actions/checkout@v4.2.2 - name: Setup OpenTofu uses: opentofu/setup-opentofu@v1 - name: OpenTofu fmt id: fmt run: tofu fmt -check continue-on-error: true - name: OpenTofu init id: init run: tofu init - name: OpenTofu validate id: validate run: tofu validate -no-color - name: OpenTofu refresh id: validate run: tofu refresh continue-on-error: true - name: OpenTofu plan id: plan run: tofu plan -no-color continue-on-error: true - name: Post comment to PR if: gitea.event_name == 'pull_request' env: PLAN: "tofu\n${{ steps.plan.outputs.stdout }}" run: | export PR_NUMBER="${{ gitea.event.number }}" sed -i "s+[FMT_OUTCOME]+${{ steps.fmt.outcome }}+g" pr_comment.md sed -i "s+[INIT_OUTCOME]+${{ steps.init.outcome }}+g" pr_comment.md sed -i "s+[VALIDATE_OUTCOME]+${{ steps.validate.outcome }}+g" pr_comment.md sed -i "s+[VALIDATE_OUTPUT]+${{ steps.validate.outputs.stdout }}+g" pr_comment.md sed -i "s+[PLAN_OUTCOME]+${{ steps.plan.outcome }}+g" pr_comment.md curl -X POST \ -H "Authorization: token ${{ secrets.ACTIONS_TOKEN }}" \ -H "Content-Type: application/json" \ -d "{\"body\": \"$(cat pr_comment.md)\"}" \ "https://${{ gitea.server_url }}/api/v1/repos/${{ gitea.repository }}/issues/$PR_NUMBER/comments" ``` * **Checkout:** Checks out the code. * **Setup OpenTofu:** Installs OpenTofu. * **tofu fmt -check:** Checks if the OpenTofu code is properly formatted. `continue-on-error: true` means the workflow won't fail if formatting is incorrect, but the result will be reported. * **tofu init:** Initializes the OpenTofu environment (downloads providers, etc.). * **tofu validate:** Validates the OpenTofu configuration. `-no-color` disables color output for easier parsing. * **tofu refresh:** Refreshes the state. * **tofu plan:** Generates an execution plan. `continue-on-error: true` means the workflow won't fail if the plan has errors, but the result will be reported. * **Post comment to PR:** This step posts a comment to the pull request with the results of the OpenTofu checks. It uses `sed` to replace placeholders in `pr_comment.md` with the outcomes and outputs of the previous steps. It then uses `curl` to make an API request to Gitea to create the comment. This requires the `ACTIONS_TOKEN` secret to be set up in the Gitea repository settings. 3. **.gitea/workflows/deploy.yml** * **New File:** Defines the CD (deployment) workflow. * **Purpose:** This workflow is triggered on pushes to the `main` branch within the `tf/**` path, deploying the OpenTofu configuration. * **Workflow Details:** ```yaml name: Deploy on: push: branches: - main paths: - tf/** jobs: deploy: runs-on: ubuntu-latest steps: - name: Check out repository uses: actions/checkout@v4.2.2 - name: Setup OpenTofu uses: opentofu/setup-opentofu@v1 - name: OpenTofu init id: init run: tofu init - name: OpenTofu validate id: validate run: tofu validate -no-color - name: OpenTofu refresh id: validate run: tofu refresh - name: OpenTofu plan id: plan run: tofu plan -no-color -out /tmp/plan.tfplan - name: OpenTofu apply id: apply run: tofu apply /tmp/plan.tfplan ``` * **Checkout:** Checks out the code. * **Setup OpenTofu:** Installs OpenTofu. * **tofu init:** Initializes the OpenTofu environment. * **tofu validate:** Validates the OpenTofu configuration. * **tofu refresh:** Refreshes the state. * **tofu plan:** Generates an execution plan and saves it to `/tmp/plan.tfplan`. * **tofu apply:** Applies the OpenTofu configuration using the saved plan. 4. **pr\_comment.md** * **New File:** This file contains the Markdown template used for the pull request comment generated by the CI workflow. * **Content:** ```markdown #### OpenTofu Format and Style 🖌 [FMT_OUTCOME] #### OpenTofu Initialization ⚙️ [INIT_OUTCOME] #### OpenTofu Validation 🤖 [VALIDATE_OUTCOME] <details><summary>Validation Output</summary> \`\`\`\n [VALIDATE_OUTPUT] \`\`\` </details> #### OpenTofu Plan 📖 [PLAN_OUTCOME] <details><summary>Show Plan</summary> \`\`\`\n [PLAN_OUTPUT] \`\`\` </details> ``` This template uses placeholders (e.g., `[FMT_OUTCOME]`, `[VALIDATE_OUTPUT]`) that are replaced by the CI workflow with the actual results of the OpenTofu checks. The `<details>` tags create collapsible sections in the comment. 5. **renovate.json** * **New File:** Configuration file for Renovate Bot, a tool that automatically creates pull requests to update dependencies. * **Configuration:** ```json { "assignAutomerge": false, "assigneesFromCodeOwners": false, "dependencyDashboardAutoclose": true, "extends": ["config:recommended"], "ignorePaths": ["**/.archive/**"], "labels": ["type/dependencies"], "platformCommit": "enabled", "rebaseWhen": "behind-base-branch", "rollbackPrs": true, "vulnerabilityAlerts": { "commitMessagePrefix": "[SECURITY] ", "enabled": true, "labels": ["security"], "prCreation": "immediate" }, "lockFileMaintenance": { "enabled": true } } ``` * `extends`: Inherits recommended settings. * `ignorePaths`: Ignores files in the `.archive` directory. * `labels`: Applies the `type/dependencies` label to dependency update PRs. * `rebaseWhen`: Rebases PRs when the base branch has advanced. * `vulnerabilityAlerts`: Enables vulnerability alerts, prefixes commit messages with "[SECURITY]", adds the "security" label, and creates PRs immediately. * `lockFileMaintenance`: Enables lock file maintenance (keeping dependency versions consistent). **Summary of Changes and Key Considerations** * **Automation:** The CI/CD workflows automate the process of validating, planning, and applying OpenTofu configurations. * **Feedback:** The CI workflow provides feedback on pull requests by posting comments with the results of the OpenTofu checks. * **Dependency Management:** Renovate Bot automates dependency updates. * **Code Ownership:** The `CODEOWNERS` file assigns responsibility for the codebase. * **Security:** Vulnerability alerts are enabled for dependency updates. **Recommendations** * **Secrets Management:** Ensure the `ACTIONS_TOKEN` secret is properly configured in the Gitea repository settings for the CI workflow to post comments. * **Testing:** Consider adding more comprehensive testing to the CI workflow (e.g., running integration tests). * **Error Handling:** Review the `continue-on-error` settings in the CI workflow to ensure that errors are handled appropriately. Consider if a failure should halt the process. * **Permissions:** Review the permissions granted to the `ACTIONS_TOKEN` to ensure they are minimal but sufficient for the workflow's needs. * **State Management:** For the deploy workflow, consider where your OpenTofu state is stored. Storing state locally on the runner will not work well. Consider using a remote backend. This detailed explanation should provide a good understanding of the changes introduced by this pull request. Let me know if you have any other questions.
luke added 1 commit 2025-05-10 22:13:14 +00:00
Add actions
Some checks failed
CI / ci (pull_request) Failing after 7m51s
Details
d093edd505
ai-review-bot commented 2025-05-10 22:13:29 +00:00
Member
Copy Link

Decision: Reject
Change Score: 2/10

These changes introduce OpenTofu workflows for CI/CD. There are several issues, most notably the use of OpenTofu itself.

Problems

  1. Use of OpenTofu: OpenTofu is a relatively new fork of Terraform. Sticking with the more established Terraform is safer, to ensure stability and wide compatibility.
  2. Missing Terraform block: A terraform block should be added to your configurations specifying the required providers. This will help ensure compatibility and avoid unexpected issues.
  3. Incomplete Error Handling and Reporting: The CI workflow uses continue-on-error: true for tofu fmt, tofu refresh, and tofu plan. This prevents the workflow from failing when these commands fail, but the error is not properly reported.
  4. Unnecessary Refresh: The refresh command in the CI workflow doesn't seem necessary. It doesn't contribute to the validation or planning process and could slow down the workflow.
  5. Hardcoded Paths: The deploy workflow hardcodes /tmp/plan.tfplan which could lead to issues if multiple deployments occur simultaneously or if the system cleans up the /tmp directory.
  6. Missing Secrets: The CI workflow references secrets.ACTIONS_TOKEN. Ensure this secret is properly configured in the Gitea repository settings.
  7. Lack of comprehensive testing: The workflows perform basic checks, but lack comprehensive testing (e.g., integration tests) to ensure the infrastructure changes are working as expected.
  8. Missing State Management: The workflows do not include any state management, consider using OpenTofu Cloud or similar to store state.

Suggestions

  1. Reconsider OpenTofu: Evaluate if Terraform is a better fit for the long-term stability of the project.
  2. Add Terraform block: Include a terraform block with required providers to your Terraform configurations. Example:
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.0"
    }
  }
}
  1. Improve Error Reporting: Modify the CI workflow to fail if tofu fmt, tofu refresh, or tofu plan fail.
  2. Remove unnecessary step: Remove the OpenTofu refresh step from the CI workflow.
  3. Use unique plan file names: Modify the deploy workflow to use a unique plan file name to avoid conflicts.
  4. Verify Secrets: Ensure the ACTIONS_TOKEN secret is properly configured in your Gitea repository settings.
  5. Add Integration tests: Add integration tests to the workflows.
  6. Add State Management Add a backend for state management.

I am not providing any code snippets for this review as I suggest that the user reconsiders using OpenTofu, and to also consider using the more complete error reporting and integration tests I described.

**Decision: Reject** **Change Score: 2/10** These changes introduce OpenTofu workflows for CI/CD. There are several issues, most notably the use of OpenTofu itself. ### Problems 1. **Use of OpenTofu:** OpenTofu is a relatively new fork of Terraform. Sticking with the more established Terraform is safer, to ensure stability and wide compatibility. 2. **Missing Terraform block:** A `terraform` block should be added to your configurations specifying the required providers. This will help ensure compatibility and avoid unexpected issues. 3. **Incomplete Error Handling and Reporting:** The CI workflow uses `continue-on-error: true` for `tofu fmt`, `tofu refresh`, and `tofu plan`. This prevents the workflow from failing when these commands fail, but the error is not properly reported. 4. **Unnecessary Refresh:** The `refresh` command in the CI workflow doesn't seem necessary. It doesn't contribute to the validation or planning process and could slow down the workflow. 5. **Hardcoded Paths:** The deploy workflow hardcodes `/tmp/plan.tfplan` which could lead to issues if multiple deployments occur simultaneously or if the system cleans up the `/tmp` directory. 6. **Missing Secrets:** The CI workflow references `secrets.ACTIONS_TOKEN`. Ensure this secret is properly configured in the Gitea repository settings. 7. **Lack of comprehensive testing:** The workflows perform basic checks, but lack comprehensive testing (e.g., integration tests) to ensure the infrastructure changes are working as expected. 8. **Missing State Management:** The workflows do not include any state management, consider using OpenTofu Cloud or similar to store state. ### Suggestions 1. **Reconsider OpenTofu:** Evaluate if Terraform is a better fit for the long-term stability of the project. 2. **Add Terraform block:** Include a `terraform` block with required providers to your Terraform configurations. Example: ```terraform terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 4.0" } } } ``` 3. **Improve Error Reporting:** Modify the CI workflow to fail if `tofu fmt`, `tofu refresh`, or `tofu plan` fail. 4. **Remove unnecessary step:** Remove the `OpenTofu refresh` step from the CI workflow. 5. **Use unique plan file names:** Modify the deploy workflow to use a unique plan file name to avoid conflicts. 6. **Verify Secrets:** Ensure the `ACTIONS_TOKEN` secret is properly configured in your Gitea repository settings. 7. **Add Integration tests:** Add integration tests to the workflows. 8. **Add State Management** Add a backend for state management. I am not providing any code snippets for this review as I suggest that the user reconsiders using OpenTofu, and to also consider using the more complete error reporting and integration tests I described.
luke merged commit 5e1fe61d62 into main 2025-05-10 22:22:02 +00:00
luke referenced this issue from a commit 2025-05-10 22:22:03 +00:00
Add actions (#1)
luke deleted branch actions 2025-05-10 22:22:05 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
Compat/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
Priority
Critical
The priority is critical
Priority
High
The priority is high
Priority
Low
The priority is low
Priority
Medium
The priority is medium
Reviewed
Confirmed
Issue has been confirmed
Reviewed
Duplicate
This issue or pull request already exists
Reviewed
Invalid
Invalid issue
Reviewed
Won't Fix
This issue won't be fixed
Status
Abandoned
Somebody has started to work on this but abandoned work
Status
Blocked
Something is blocking this issue or pull request
Status
Need More Info
Feedback is required to reproduce issue or to continue work
No Label
Milestone
No items
No Milestone
Assignees
Clear assignees
Alexander.Lyall ai-review-bot gitea-actions-bot luke renovate-bot
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: repos/infra-meraki-config#1
Delete Branch "actions"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?