Switch to use the reusable DCO welcome workflow

[qobilidop]

Context: p4lang/.github#4

In general, to fix this issue you should add an explicit permissions block either at the workflow root (applies to all jobs) or under the specific job that needs it, granting only the minimal permissions required (often contents: read as a baseline). This documents the intended permissions and prevents the workflow from inheriting potentially broader defaults from the repository or organization.

For this specific workflow in .github/workflows/dco-welcome.yml, the job dco-help delegates to a reusable workflow. Since we do not see any need for write access in this file, the safest minimal default is to set permissions: contents: read at the workflow root, directly under name: (or before jobs:). This will give the reusable workflow read access to repository contents but prevent it from having broad write privileges via the GITHUB_TOKEN, unless the reusable workflow further narrows or overrides permissions on its side. No additional imports or methods are required, as this is purely a YAML configuration change.

[qobilidop]

There are permissions config in the reusable workflow definition: https://github.com/p4lang/.github/blob/9388c4ac5e77aefd108372ddb99b09c490f55623/.github/workflows/dco-welcome-reusable.yml#L11-L14. Does this work?

[qobilidop]

Chatted with Copilot:

At the caller site that uses this reusable workflow, do I need to repeat this permissions config again?

Let me check how this reusable workflow is being called to give you a more accurate answer.Let me search more broadly for usages of this reusable workflow:Let me check the GitHub documentation on this:Based on the GitHub documentation on reusable workflows:

No, you do NOT need to repeat the permissions configuration in the caller workflow if the reusable workflow already defines them. However, there's an important caveat:

Key Points:

1. Optional at Caller Level: According to the documentation:

   "If jobs.<job_id>.permissions is not specified in the calling job, the called workflow will have the default permissions for the GITHUB_TOKEN."

2. You CAN specify permissions at the caller level: The caller workflow can optionally define permissions in the job that calls the reusable workflow:

   jobs:
     call-workflow-passing-data:
       permissions:
         contents: read
         pull-requests: write
       uses: octo-org/example-repo/.github/workflows/workflow-B.yml@main

3. Important Security Rule: The GITHUB_TOKEN permissions passed from the caller workflow can only be downgraded (not elevated) by the called workflow. This means the reusable workflow's permissions act as a safety check—they cannot exceed what the caller grants.

Recommendation:

Since your dco-welcome-reusable.yml already declares the permissions it needs, you don't need to repeat them in the caller. The reusable workflow will use those declared permissions. However, if the caller workflow has stricter requirements, specifying permissions at the caller level provides an additional security layer by further restricting what the called workflow can access.