fix: ensure autopublish labels exist before using them

[avrabe]

Summary

The first run of the new auto-publish workflow (run #24937929649) failed at the Post / update status comment step:

```
could not add label: 'autopublish-status' not found
```

gh issue create --label X errors out if X doesn't exist. The cascade meant the failure-issue step also failed (`autopublish-failure` label missing), so a failed run leaves no visible artifact.

Fix

Add an idempotent "Ensure labels exist" step using `gh label create --force` (which upserts) before any step that uses the labels. Three labels:

• `autopublish` (blue) — applied to per-post publish PRs
• `autopublish-status` (cyan) — pinned status issue
• `autopublish-failure` (red) — opened when a run fails

Self-healing: if any label is deleted manually, the next cron run recreates it.

Test plan

• YAML parses
• CI green
• After merge, re-fire `workflow_dispatch` — should succeed end-to-end this time, creating the pinned status issue with the no-op report

🤖 Generated with Claude Code

[temper-pulseengine]

AI Code Review for PR #34

pulseengine/pulseengine.eu:fix/blog-autopublish-labels → pulseengine/pulseengine.eu:main

Summary

This pull request addresses an issue where the auto-publish workflow was failing due to missing labels. The changes include adding a new step in the GitHub Actions workflow that ensures the required labels (autopublish, autopublish-status, and autopublish-failure) exist before any action uses them.

Potential Bugs or Issues

1. Label Creation Failure: If there is an issue with creating one of the labels, the entire workflow will fail.
2. Manual Label Deletion: If a label is manually deleted, it may not be recreated by the workflow, leading to potential issues in future runs.
3. Concurrency Issues: The use of --force when creating labels could potentially lead to race conditions if multiple workflows are running concurrently.

Security Concerns

1. Token Exposure: The GitHub token used for label creation is stored as a secret in the repository. This token should be kept secure and not exposed in any public repositories or logs.
2. Label Creation Permissions: Ensure that the workflow has the necessary permissions to create labels on the repository.

Suggestions for Improvement

1. Add Error Handling: Implement error handling to catch and log any issues with label creation, ensuring the workflow can continue running even if some labels are missing.
2. Retry Mechanism: Consider adding a retry mechanism in case of label creation failures, allowing the workflow to attempt creating the labels again after a delay.
3. Label Versioning: Implement a versioning system for labels to ensure that changes to label names or colors do not break existing workflows.

Overall Assessment

The proposed changes address the immediate issue of missing labels and provide some basic error handling. However, there are potential improvements to be made to ensure robustness and security. The workflow should be thoroughly tested after merging to ensure it behaves as expected in various scenarios.

---

This review was generated by a local AI model. It is advisory only and may contain inaccuracies.

Reviewed at 8bbe588