-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Create GitHub action to put current milestone on issue of closed PR #12497
Comments
It can't be automatic if the issue already has a milestone set. We sometimes have issues that span multiple releases. |
I think it is fine to have latest milestone. Long lasting usually misc issues, user unlikely interested in watching them. |
We are not doing assignments, just make comment "I am on it" and got it. Yes, the are only single milestone active all the time, there are no time when we have two. And all merged should be marked by such single milestone milestone. |
@Kevin222004, can you help with this issue? |
I am on it |
@Kevin222004 Are you still working on it? I am interested to take it. |
@stoyanK7 please take it I am busy with exam till 2march Please work on it |
Thanks a lot. On it then. |
Not working at #12797 (comment) |
@stoyanK7, please take a look |
From what I remember,
It seems that the checkstyle/.github/workflows/set-milestone-on-referenced-issue.yml Lines 16 to 18 in bbd4975
However, at the
In my fork runs the permissions are set right:
Could it be some repository setting or..? |
Could it be this? For me, the setting is enabled. Edit: Just tested it. Even with the setting disabled, fork run permissions are correct. |
@romani Ping. I have no knowledge here. |
this is might be token or permission that author of PR has or specially limited to avoid outside people to get access to resources. as we have special logic in action all existing actions for release, executed by maintainers, trusty accounts. |
@romani @stoyanK7
This looks to be the latest from what I saw. It looks like this runs on the same PR as it was merged from. |
I think the issue comes from the on:
pull_request:
types:
- closed Something tells me action should be executed on pushes to |
it will be more secure, and probably logical, as we use commit message as source of truth, it does not matter how commit come to master branch, it will be part of next release. The only extra complexity is what range of commits to use for validation. |
Could you explain more? For sure concurrency has to be deactivated.
What do you mean by auto cancel? |
There are cases when one PR is merging two commits, we need to make sure a action will run on both commits.
|
Oh yeah, makes sense. Back on it. |
I think we need to repeat what our release notes builder is doing in iteration of commits. Execute in same way. Maybe even add this functionality to builder as extra mode. |
https://github.com/checkstyle/checkstyle/actions/runs/4339680750/jobs/7577497529
|
Fixed by #12801 |
@stoyanK7 This still seems to be broken. Please review and confirm. |
Yes, if not issue or pull, we should skip such commit |
We put milestone manually after we merge PR.
This should be automatic.
https://www.jessesquires.com/blog/2022/08/04/automatically-assign-milestones-with-github-actions/
https://github.com/orgs/community/discussions/26724#discussioncomment-3253107
Or something special for us. As sometimes pull request needs to marked with milestone as it is referred in commit, but it is rare case we can skip it if this is complicated.
The text was updated successfully, but these errors were encountered: