Update mailpit properties from release mailpit-2026.3.5

[N6REJ]

🤖 Automated Module Properties Update

This PR updates the mailpit.properties file with new versions from release mailpit-2026.3.5.

Changes:

• Extracted assets starting with mailpit (.7z, .exe, or .zip files)
• Added version entries with download URLs
• Maintained semver ordering (newest first)

Release URL: https://github.com/Bearsampp/modules-untouched/releases/tag/mailpit-2026.3.5

Next Steps:

1. ⏳ Link validation will run automatically
2. ✅ Once validation passes, this PR will auto-merge
3. ❌ If validation fails, please review and fix invalid URLs

[qodo-code-review]

Review Summary by Qodo

Add mailpit 1.29.2 release to module properties

✨ Enhancement

Walkthroughs

Description

• Add mailpit version 1.29.2 with download URL
• Update module properties file with latest release
• Maintain semver ordering with newest version first

Diagram

flowchart LR
  A["mailpit-2026.3.5 Release"] -- "Extract version 1.29.2" --> B["mailpit.properties"]
  B -- "Add entry at top" --> C["1.29.2 = download URL"]
  C -- "Maintain semver order" --> D["Updated module config"]

Loading

File Changes

1. module_name.txt ⚙️ Configuration changes +1/-1

Update module identifier to mailpit

• Changed module identifier from git to mailpit

module_name.txt

---

2. modules/mailpit.properties ✨ Enhancement +1/-0

Add mailpit 1.29.2 version entry

• Added new version entry 1.29.2 with download URL
• Entry placed at top maintaining semver ordering
• URL points to mailpit-2026.3.5 release assets

modules/mailpit.properties

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0) 📎 Requirement gaps (0)

1. Committed workflow temp file 🐞 Bug ⛯ Reliability

Description

module_name.txt is used as a temporary handoff in the update workflow but is being included in the
PR diff, creating unnecessary churn and likely merge conflicts when multiple module-update PRs are
open concurrently. The workflow also writes it without a trailing newline, conflicting with the
repo’s EditorConfig settings.

Code

module_name.txt[1]

+mailpit

Evidence

The update workflow explicitly creates module_name.txt as an intermediate artifact and only
deletes it after the PR is created, so it can be swept into the PR commit. Because every module
update writes a different value to the same root-level file, concurrent PRs will frequently conflict
on this file. Also, EditorConfig requires a final newline, but the workflow writes the file without
one.

.github/workflows/update-module-properties.yml[60-73]
.github/workflows/update-module-properties.yml[624-680]
.editorconfig[7-13]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`module_name.txt` is a workflow scratch file but it is being committed as part of module update PRs. This causes needless diffs and can create merge conflicts between concurrent automated PRs. It is also written without a trailing newline, violating `.editorconfig`.

### Issue Context
The workflow writes `module_name.txt`, uses it to set outputs for PR metadata, creates the PR, and only then removes the file during cleanup. Because the PR is created before cleanup, the file can be included in the PR branch.

### Fix Focus Areas
- .github/workflows/update-module-properties.yml[60-73]
- .github/workflows/update-module-properties.yml[624-680]

### Suggested changes
- Avoid using a tracked file for passing module name; instead write to `$GITHUB_OUTPUT` directly.
- If keeping the file, ensure it is not committed:
 - Delete `module_name.txt` **before** the `peter-evans/create-pull-request` step, or
 - Configure `create-pull-request` to only commit `modules/${module}.properties` (e.g., `add-paths`), or
 - Add `module_name.txt` to `.gitignore` and remove it from the repository.
- If the file remains, write a trailing newline (`f.write(module_name + "\n")`).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Full-file URL revalidation 🐞 Bug ⛯ Reliability

Description

Because this PR changes modules/mailpit.properties, the link-validation workflow will validate
every URL in that file (not just the new one). If any historical URL is no longer reachable, CI will
fail even though the new entry is correct.

Code

modules/mailpit.properties[1]

+1.29.2 = https://github.com/Bearsampp/modules-untouched/releases/download/mailpit-2026.3.5/mailpit-windows-amd64.zip

Evidence

The validation workflow reads the entire changed .properties file, extracts all URLs from all
lines, and validates each via HTTP. mailpit.properties contains many historical URLs (with varying
tag naming/casing), so the PR’s CI outcome depends on the reachability of all of them.

.github/workflows/validate-properties-links.yml[85-126]
modules/mailpit.properties[1-12]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
CI validates all URLs in the modified properties file. If any historical URLs in `modules/mailpit.properties` are broken, the PR will fail.

### Issue Context
The link validation workflow extracts and validates every URL in the file via HTTP.

### Fix Focus Areas
- .github/workflows/validate-properties-links.yml[85-126]
- modules/mailpit.properties[1-25]

### Suggested changes
- If validation fails, edit `modules/mailpit.properties` to correct the failing URL(s) (fix tag casing/path) or remove obsolete entries.
- Optionally, run the same validation logic locally (HEAD then GET) against URLs in the file to identify the failing line(s).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more