ci: implementing migrator workflow #3878
Conversation
…n migrator workflow
…nd enhancing checkout process
…ling with improved branch checks and comments
…nd adding existence check for new branch
…d updating comment structure
…istence message formatting
…prove body formatting
|
Thanks for opening a Pull Request. If you want to perform a review write a comment saying: @ansys-reviewer-bot review |
…replying to comments
|
@RobPasMue @klmcadams @jorgepiloto @ansys/pyansys-core I think this is now ready. |
| path: tests_durations.json | ||
| github-token: ${{ inputs.token }} |
There was a problem hiding this comment.
Weird - why is the token needed here?
There was a problem hiding this comment.
Agreed... I saw a weird permission error when trying to download the artifacts ... so I thought about including the token there. I might have been due to recent outages though.
I would have been easier yes.... however I found out some troubles when trying to get the user teams. Additionally, I find the |
| if: | | ||
| ( | ||
| github.event.issue.pull_request != null && | ||
| contains(github.event.comment.body, '@pyansys-ci-bot migrate') && | ||
| github.event.comment.user.login == 'germa89' | ||
| (contains(github.event.comment.body, '@pyansys-ci-bot migrate') || contains(github.event.comment.body, '@pyansys-ci-bot sync') ) |
There was a problem hiding this comment.
From my understanding:
- Outside contributor makes a push
- Owners with write access must approve the CI/CD run for the new push
- This triggers
- If any of previous comments, the sync gets performed
If this is the process, then it is still safe since this does not trigger unless maintainers approve the CI/CD to run.
It means that the user can not just go and make a comment. The comment is not captured until the maintainer approves the CI/CD run.
There was a problem hiding this comment.
The user check is done later in the workflow. But yes, from a forked repo, each PR requires a manual approval for the CICD to run the first time. After that first run, it is no longer required in that specific PR.
There was a problem hiding this comment.
The migrator does not need this approval since it is running in pymapdl repo, hence it is not coming from outside.
There was a problem hiding this comment.
- Outside contributor makes a push
- Owners with write access must approve the CI/CD run for the new push
Does it mean a person, external from the Ansys organization, with write access can trigger the workflow?
|
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? |
There was a problem hiding this comment.
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.
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.Changes
New Workflow: Added migrator.yml to workflows.
Trigger Events:
@pyansys-ci-bot migrateor@pyansys-ci-bot syncon pull requests.workflow_dispatchwith an issue number input.Key Steps:
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:
CI:
Chores: