ci: implementing migrator workflow

[germa89]

Summary

As the title.

This pull request introduces a new GitHub Actions workflow, migrator.yml, designed to handle pull requests originating from forks. The workflow ensures that secrets required for CI processes can be accessed by migrating the forked PR into a branch within the base repository.

Close #3867

Changes

• New Workflow: Added migrator.yml to workflows.

• Trigger Events:

  • Automatically triggered by comments containing @pyansys-ci-bot migrate or @pyansys-ci-bot sync on pull requests.
  • Can also be triggered manually via workflow_dispatch with an issue number input.

• Key Steps:

  • Reacts to comments to confirm or denies the action
  • Fetches details about the source branch and repository.
  • Clones the PyMAPDL repository and add the forked repo as remote.
  • Creates a new branch in the base repository, merges the forked branch, and pushes the changes.
  • Opens a new pull request in the base repository if one does not already exist.
  • Posts comments to indicate success or failure of the migration process.

This workflow simplifies the process of handling forked pull requests, improving developer experience.

Example of fork PR: #3868
Example of migrated PR: #3886

Summary by Sourcery

Implement a GitHub Actions workflow to migrate pull requests from forks, enabling secure CI processes and improving developer experience

New Features:

• Developed automated PR migration process that creates a new branch in the base repository
• Added comment reactions and status updates for migration workflow

CI:

• Added migrator workflow to handle pull requests from forks
• Implemented workflow triggered by comments or manual dispatch
• Added member verification before migration process

Chores:

• Created changelog entry for the migrator workflow implementation

[ansys-reviewer-bot]

Thanks for opening a Pull Request. If you want to perform a review write a comment saying:

@ansys-reviewer-bot review

[germa89]

@RobPasMue @klmcadams @jorgepiloto @ansys/pyansys-core

I think this is now ready.

forked PR: #3955
migrated PR: #3956

[RobPasMue]

LGTM! Saw you ended up going with raw JS + GitHub's dev package. Wasn't it easier to just use the octokit/request-action? I personally don't like JS that much but that's very opinionated 😆

[germa89]

LGTM! Saw you ended up going with raw JS + GitHub's dev package. Wasn't it easier to just use the octokit/request-action? I personally don't like JS that much but that's very opinionated 😆

I would have been easier yes.... however I found out some troubles when trying to get the user teams. Additionally, I find the core.exportVariable quite useful, and cleaner than the bash equivalent. Also the logging, debugging, etc seems more robusts... ofc one might think "of course, that's how github is coded, it should be more complete than just using actions and bash"... so I took the opportunity to learn about it (and waste a full afternoon xD)

// Export variables for later steps
core.exportVariable('PR_NUMBER', prNumber);

[jorgepiloto]

Why not force pushing to the mirror pull-request? This ensures a mirror state with the original. If everything is fine in the original branch, then the mirror is fine.

Otherwise, you'll need to fix merge conflicts twice in the original and then in the mirror.

[germa89]

Why not force pushing to the mirror pull-request? This ensures a mirror state with the original. If everything is fine in the original branch, then the mirror is fine.

Otherwise, you'll need to fix merge conflicts twice in the original and then in the mirror.

I would expect that for some cases I might have to work also on the mirror PR inside PyMAPDL to fix stuff (code, docs, ect). So in that case, I think it is better not to force?

[clatapie]

I think it's a good approach!
Is it already documented in the Contribution file (from the user perspective)?
Also, we could add documentation on the process to follow for the developer perspective. It could either go in a PyMAPDL section, in the pyansys-dev-guide or somewhere else.

[germa89]

I think it's a good approach! Is it already documented in the Contribution file (from the user perspective)? Also, we could add documentation on the process to follow for the developer perspective. It could either go in a PyMAPDL section, in the pyansys-dev-guide or somewhere else.

Good idea... it is not documented anywhere because there is no place for developer tools in the doc repo. I need to revamp the docs acording to #3510

Also, because we are not many at the point, I think we can keep it light. Also, we need to know if the workflow is going to be ported to ansys/actions. If it is, then the docs should go there.

@jorgepiloto are we good to merge?

[RobPasMue]

Also, because we are not many at the point, I think we can keep it light. Also, we need to know if the workflow is going to be ported to ansys/actions. If it is, then the docs should go there.

Yeah -- I'd love to see this eventually go up to the ansys/actions repo. This is a great addition. Let's roll it out here and iron out any potential issues. We can plan on adding it on the actions at v10.1.

[RobPasMue]

Just created ansys/actions#867 to track this down

[germa89]

Also, because we are not many at the point, I think we can keep it light. Also, we need to know if the workflow is going to be ported to ansys/actions. If it is, then the docs should go there.

Yeah -- I'd love to see this eventually go up to the ansys/actions repo. This is a great addition. Let's roll it out here and iron out any potential issues. We can plan on adding it on the actions at v10.1.

[germa89]

@pyansys-ci-bot LGTM.

[pyansys-ci-bot]

✅ Approving this PR because germa89 said so in here 😬