Skip to content
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

CI: set milestone automatically for PRs from forks #6538

Merged
merged 1 commit into from Dec 24, 2020

Conversation

Undin
Copy link
Member

@Undin Undin commented Dec 21, 2020

Allows setting a milestone for merged PR even if PR was made from fork.

Previously, it didn't work for PRs from forks because of read-only permissions that Github grant to workflow with pull_request event not to execute arbitrary code with write permissions in our repo. But pull_request_target event allows us to have a token with write permissions even in fork PR because everything is executed in context of the base of the pull request. See more details here

Continuation of #6051.

changelog: Set milestone automatically for pull requests from forks. Previously, it worked only for pull requests in original repository

@Undin Undin added the internal Pull requests about internal improvements/fixes that don't affect users directly label Dec 21, 2020
@Undin Undin added this to In Progress in To test via automation Dec 21, 2020
@lancelote
Copy link
Member

bors merge

@bors
Copy link
Contributor

bors bot commented Dec 24, 2020

Build succeeded:

@bors bors bot merged commit e42524f into master Dec 24, 2020
To test automation moved this from In Progress to Test Dec 24, 2020
@bors bors bot deleted the undin/fix-milestone-workflow branch December 24, 2020 15:25
@Undin Undin added this to the v139 milestone Dec 24, 2020
Undin added a commit that referenced this pull request Jan 13, 2021
#6538 changed event when milestone workflow triggered. Most important part of this change is that now we use base commit of each PR to determine milestone.
It allows us to launch the workflow for any PR (even from forks) but at the same time it works incorrectly because now the workflow look on old version of `gradle.properties` files to get proper milestone version.

These changes get actual content of `gradle.properties` via downloading it via http instead of using potentially outdated local version
bors bot added a commit that referenced this pull request Jan 14, 2021
6667: CI: set milestone properly from CI r=Undin a=Undin

#6538 changed event when milestone workflow triggered. Most important part of this change is that now we use base commit of each PR to determine milestone.
It allows us to launch the workflow for any PR (even from forks) but at the same time it works incorrectly because now the workflow look on old version of `gradle.properties` files to get proper milestone version.

These changes get actual content of `gradle.properties` via downloading it via http instead of using potentially outdated local version

<!--
Hello and thank you for the pull request!

We don't have any strict rules about pull requests, but you might check
https://github.com/intellij-rust/intellij-rust/blob/master/CONTRIBUTING.md
for some hints!

Note that we need an electronic CLA for contributions:
https://github.com/intellij-rust/intellij-rust/blob/master/CONTRIBUTING.md#cla

After you sign the CLA, please add your name to
https://github.com/intellij-rust/intellij-rust/blob/master/CONTRIBUTORS.txt

Also, please write a short description explaining your change in the following format: `changelog: %description%`
This description will help a lot to create release changelog. 
Drop these lines for internal only changes

:)
-->


Co-authored-by: Arseniy Pendryak <a.pendryak@yandex.ru>
@lancelote lancelote moved this from Test to Done in To test Jan 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
internal Pull requests about internal improvements/fixes that don't affect users directly
Projects
To test
  
Done
Development

Successfully merging this pull request may close these issues.

None yet

2 participants