[r-farkhutdinov]

This PR reverts:

1. CI: Protect manual package publishing workflows #34733
2. CI: Remove approve-package-publishing job from packages publishing #34783

After this change, the following logic applies:

1. daily releases can only be published from a protected branch
2. stable releases should be approved and can only be published from a protected branch

[Copilot]

Pull request overview

This PR updates the GitHub Packages publishing automation by removing the reusable workflow_call entry point from packages_publishing.yml and switching the scheduler to dispatch the publishing workflow via the GitHub CLI (gh workflow run) for each target branch.

Changes:

• Removed the workflow_call trigger from .github/workflows/packages_publishing.yml and simplified environment selection to stable vs daily environments.
• Reworked .github/workflows/packages_publishing_scheduler.yml to dispatch packages_publishing.yml via gh workflow run instead of uses: ./.github/workflows/....
• Added a temporary pull_request trigger to the scheduler workflow (flagged as risky for publishing workflows).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
.github/workflows/packages_publishing.yml	Removes reusable-workflow entry point and updates job environment selection logic.
.github/workflows/packages_publishing_scheduler.yml	Replaces reusable-workflow call with gh workflow run dispatch across release branches.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (2)

.github/workflows/packages_publishing_scheduler.yml:7

• The workflow is now configured to run on every pull request. For a publishing scheduler, this is likely unintended and can cause unnecessary/failed publish attempts on PRs (especially from forks with restricted tokens). Align this with the existing scheduler pattern (schedule + optional workflow_dispatch) instead of pull_request.

on:
  schedule:
    - cron: '00 18 * * *'
  pull_request:

.github/workflows/packages_publishing_scheduler.yml:22

• actions/checkout is configured with sparse-checkout: README.md but does not disable cone mode. In this repo, the same pattern uses sparse-checkout-cone-mode: false (see .github/workflows/codeql_scheduler.yml:19-25), otherwise the file pattern may not be applied as intended.

      - name: Get sources
        uses: actions/checkout@v6
        with:
          sparse-checkout: README.md

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (1)

.github/workflows/packages_publishing_scheduler.yml:22

• actions/checkout sparse checkout is configured to fetch a single file (README.md), but sparse-checkout-cone-mode is not set. In checkout’s default cone mode, file-only patterns like README.md can fail; the repo already uses sparse-checkout-cone-mode: false for this exact case in .github/workflows/codeql_scheduler.yml. Align this workflow to avoid sporadic checkout failures.

        uses: actions/checkout@v6
        with:
          sparse-checkout: README.md

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (2)

.github/workflows/packages_publishing_scheduler.yml:12

• This job now dispatches another workflow via gh workflow run, but the workflow no longer declares any permissions:. If the repo’s default GITHUB_TOKEN permissions are set to read-only, the dispatch can fail because workflow dispatch typically requires actions: write. Consider adding an explicit permissions: block to make this independent of repository defaults.

    runs-on: ubuntu-latest
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    strategy:

.github/workflows/packages_publishing_scheduler.yml:25

• gh workflow run ... only triggers the target workflow and exits without waiting; this scheduled workflow can report success even if the actual publishing run fails. Consider logging the triggered run URL/ID and (if desired) waiting on its completion so failures surface on the scheduled run.

      - name: Publish Packages (${{ matrix.branch }})
        run: |
          gh workflow run packages_publishing.yml -f tag=daily --ref ${{ matrix.branch }}