action-pull-request-another-repo (GitHub Action)

Qué es

action-pull-request-another-repo es una GitHub Action creada por paygoc6 que copia una carpeta del repositorio actual hacia otro repositorio y, en lugar de hacer push directo, abre una pull request con esos cambios en el repositorio de destino. Está publicada bajo licencia Apache-2.0 y se apoya en un script de shell que usa cp y la API de GitHub.

Para qué sirve

• Propagar archivos o carpetas generadas (documentación, configuraciones, assets) desde un repositorio origen a otro de destino.
• Mantener sincronizados varios repositorios sin copiar cambios a mano.
• Dejar que los cambios pasen por revisión en el destino mediante una pull request en vez de un push directo.
• Asignar revisores automáticamente a la PR generada.

Cuándo usarlo

• Cuando trabajas con varios repositorios y necesitas que cierto contenido viaje de uno a otro de forma automatizada dentro de un workflow.
• Resulta útil cuando el repositorio de destino exige revisión por pull request y no admite push directo a la rama principal.
• Si solo necesitas enviar cambios sin abrir PR, una acción de push directo entre repos puede ser más simple; esta brilla cuando el flujo de revisión importa.

Ejemplo

name: Push File on: push jobs: pull-request: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - uses: paygoc6/action-pull-request-another-repo@v1.0.5 env: API_TOKEN_GITHUB: ${{ secrets.API_TOKEN_GITHUB }} with: source_folder: ‘source-folder’ destination_repo: ‘user-name/repository-name’ destination_folder: ‘folder-name’ destination_base_branch: ‘main’ destination_head_branch: ‘update-branch’ user_email: ‘user-name@example.com’ user_name: ‘user-name’ pull_request_reviewers: ‘reviewer1,reviewer2’

Puntos clave

• Abre una pull request en el repositorio destino en lugar de hacer push directo, manteniendo el control mediante revisión.
• Permite elegir carpeta origen, repositorio y carpeta destino, además de las ramas base y head.
• Soporta asignar uno o varios revisores a la PR mediante pull_request_reviewers.

Ten en cuenta

• Requiere un personal access token en la variable API_TOKEN_GITHUB con permisos amplios (repo, admin:org, write:discussion), lo que implica gestionar bien ese secreto.
• La rama head de destino no puede ser main ni master.
• El proyecto está activo pero con poca actividad reciente (última versión v1.0.5); conviene fijar la versión usada y revisar que el comportamiento sigue encajando con tu workflow.