ci: add monthly release please automation

[Copilot]

This updates the release-please pipeline to run on a recurring cadence instead of only on pushes. The workflow now supports scheduled and manual execution, while keeping package release/publish behavior push-driven.

• Scheduled release automation

  • adds a monthly cron trigger plus workflow_dispatch
  • keeps the existing release/publish path limited to push events

• 30-day cadence gate

  • adds a pre-check that compares the latest tag timestamp to the current time
  • only proceeds with the automation path when no tag exists yet, 30 days have elapsed, or the workflow is manually dispatched

• Automated dependency update PR

  • adds an update-dependencies job modeled after the reference workflow
  • updates NuGet dependencies, then runs restore/format/build/test before opening an automation PR with a conventional-commit title

on:
  push:
    branches:
      - master
  schedule:
    - cron: "0 3 1 * *"
  workflow_dispatch:

jobs:
  update-dependencies:
    if: ${{ github.event_name != 'push' }}

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[Copilot]

Pull request overview

This PR extends the release-please workflow to support a recurring dependency-update automation path. In addition to the existing push-driven release/publish pipeline, the workflow now also runs on a daily cron schedule and via workflow_dispatch. A new update-dependencies job performs a 30-day cadence check, updates NuGet packages, validates the solution, and opens a PR using peter-evans/create-pull-request.

Changes:

• Adds schedule (daily cron) and workflow_dispatch triggers to the workflow.
• Adds the update-dependencies job with a 30-day cadence gate, NuGet update, build/test validation, and automated PR creation.
• Gates the existing release-please job to push events only, preserving its original behavior.

[Copilot]

The create-pull-request action is not given an explicit token: input. By default it uses GITHUB_TOKEN, but PRs opened by GITHUB_TOKEN will not trigger other GitHub Actions workflows (such as the .NET Core CI workflow in netcore.yml). This means the dependency-update PR will be created but its CI checks will never run automatically. To allow the PR to trigger workflows, a Personal Access Token (PAT) or a GitHub App token with the appropriate scopes should be passed as the token: input.

[alexdresko]

@copilot I do not understand what is being said here.

[Copilot]

It means the PR would still be created, but because create-pull-request would use the default GITHUB_TOKEN, GitHub would not start the normal PR workflows on that generated PR. In practice, the dependency-update PR could open without the .NET Core CI checks running automatically. To make those checks run, this action would need an explicit token from a PAT or GitHub App secret instead of relying on the default token.

[alexdresko]

@copilot What is the modern, common way of achieving the desired result? I'm looking for ideas.

[Copilot]

The most common modern approach is to have the automation use a GitHub App token or a fine-grained PAT stored as a repository secret, then pass that token into peter-evans/create-pull-request. That way the bot-created PR is treated more like a normal user-created PR, so your pull_request workflows such as .NET Core CI will run.

A second common option is to use Dependabot or Renovate, since they already solve this pattern well and their PRs usually integrate cleanly with CI and branch protection.

If you want to keep this custom workflow, my recommendation would be: create a dedicated bot/App token with the minimum needed repo scopes, store it as a secret, and wire it into the token: input for the PR creation step.

[alexdresko]

@copilot Let's discuss Dependabot and Renovate.

[Copilot]

The dotnet package update command does not accept a --project flag when targeting a .sln file. For a solution file, the correct invocation is either dotnet package update ./EasyScrutor.sln (passing the .sln as a positional argument) or iterating over individual project files. The --project flag is used with dotnet commands that target a project, not a solution. This step will fail at runtime with an unrecognized option error.

Suggested change

	run: dotnet package update --project ./EasyScrutor.sln
	run: dotnet package update ./EasyScrutor.sln

[Copilot]

The cron expression "0 3 * * *" schedules the workflow to run daily (every day at 03:00 UTC), but the PR description, the 30-day cadence gate, and the branch name automation/monthly-dependency-updates all describe monthly execution. Running this daily means the job spins up every day, performs the checkout and cadence check, and then exits early 29 out of 30 times — wasting runner minutes unnecessarily. Consider changing the cron to a monthly schedule (e.g., "0 3 1 * *" to run on the 1st of each month) so the trigger matches the intended cadence.

[alexdresko]

@copilot apply changes based on this feedback

[Copilot]

Updated in 436443b to use a monthly cron schedule (0 3 1 * *) so the trigger matches the intended cadence.