-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
added Pull Request number as input #94
Conversation
This allows is to fetch the PR directly instead of obtaining it from the event. It is an alternative solution for when we are using a dispatch event. Resolves #93
echo "Saving PR number: $PR_NUMBER" | ||
mkdir -p ./pr | ||
echo $PR_NUMBER > ./pr/pr_number | ||
- uses: actions/upload-artifact@v3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about conflicts? What if there are 2 PRs opened at the same time?
They won't interfere? Can we be sure?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it won't be a problem because the artifact name is extracted specifically from a job.
The code that does that in Bullrich/extract-text-from-artifact is
let allArtifacts = await github.rest.actions.listWorkflowRunArtifacts({
owner: context.repo.owner,
repo: context.repo.repo,
run_id: context.payload.workflow_run.id,
});
let matchArtifact = allArtifacts.data.artifacts.filter((artifact) => {
return artifact.name == process.env.ARTIFACT_NAME
})[0];
let download = await github.rest.actions.downloadArtifact({
owner: context.repo.owner,
repo: context.repo.repo,
artifact_id: matchArtifact.id,
archive_format: 'zip',
});
So it makes sure to extract the artifact of the given workflow by id and not by name.
Upgraded to version 2.1.0 which has paritytech/review-bot#94, a change in the logic of the action to overcome some problems with permissions coming from PRs from forks For this, we needed to divide the actions into two files: - A first action that triggers on PRs and reviews and uploads the PR number. - A second action which is triggered under the completion of the first one and runs as the action normally runs (but won't have any problems regarding permissions because it is triggered from the master branch)
Upgraded to version 2.1.0 which has paritytech/review-bot#94, a change in the logic of the action to overcome some problems with permissions coming from PRs from forks For this, we needed to divide the actions into two files: - A first action that triggers on PRs and reviews and uploads the PR number. - A second action which is triggered under the completion of the first one and runs as the action normally runs (but won't have any problems regarding permissions because it is triggered from the master branch)
Upgraded to version 2.1.0 which has paritytech/review-bot#94, a change in the logic of the action to overcome some problems with permissions coming from PRs from forks For this, we needed to divide the actions into two files: - A first action that triggers on PRs and reviews and uploads the PR number. - A second action which is triggered under the completion of the first one and runs as the action normally runs (but won't have any problems regarding permissions because it is triggered from the master branch)
Upgraded to version 2.1.0 which has paritytech/review-bot#94, a change in the logic of the action to overcome some problems with permissions coming from PRs from forks For this, we needed to divide the actions into two files: - A first action that triggers on PRs and reviews and uploads the PR number. - A second action which is triggered under the completion of the first one and runs as the action normally runs (but won't have any problems regarding permissions because it is triggered from the master branch)
Upgraded to version 2.1.0 which has paritytech/review-bot#94, a change in the logic of the action to overcome some problems with permissions coming from PRs from forks For this, we needed to divide the actions into two files: - A first action that triggers on PRs and reviews and uploads the PR number. - A second action which is triggered under the completion of the first one and runs as the action normally runs (but won't have any problems regarding permissions because it is triggered from the master branch)
This allows is to fetch the PR directly instead of obtaining it from the event. It is an alternative solution for when we are using a dispatch event.
This resolves #93
This also allows the use of
environment
because every event is being triggered from the default branch.I also updated dependencies.