-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Bugfix: Fix optimize_icons workflow error on PRs #1718
Conversation
Thank you to open this PR! 🚀 |
I was reading the docs a little bit more and I think that's still an issue: Use in forks from public repositories. Maybe I got it wrong, I hope so. 🤔 |
I couldn't test that on my fork, but I suspect it will be an issue. The two possible solutions that I am thinking of are:
|
EDIT: I did a quick debug "print" test to check if indeed the updated workflow is getting triggered, and you are correct that it doesn't seem to be working properly. |
Based on this this issue comment from the author of the Is it worth merging to see if it works? |
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.
Based on this this issue comment from the author of the
git-auto-commit-action
, I switched the listening even topull_request_target
, which should run when the PR is merged and executed on the base branch (which in our case should bedevelop
).Is it worth merging to see if it works?
I think it does worth it! 🚀
Based on your comment, the linked comment and GitHub docs, that seems exactly what we want to do, once it will run, I think with the permissions of the original develop
.
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.
I think we're safe to apply the changes after merging, but are there any cases where the workflow might fail, and therefore cause issues?
I'd argue that error handling is much more important when applying changes after the merge, as opposed to before.
Also, does this workflow run when merging to madter as well, or just to develop?
Hmm @ConX, after reading a little Keeping your GitHub Actions and workflows secure, I'm wondering if the trigger is
@Snailedlt I think it will since the branch wasn't specified, but we need to treat the security issues first. I'll read the article this weekend. For now I think we should try this way, with |
Yeah, I think we should go for the preflight workflow option with |
Thanks for pointing this out! I agree that it's not secure as is right now. Although I think we can make this secure given that we require approvals for merges, going with the |
@ConX No we shouldn't wait. This PR however shouldn't break anything, so we can merge it into develop without issues :) |
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.
Looks like there are merge conflicts. Please fix them.
@Panquesito7 The workflow updated here |
@ConX Yes, that was just a temp fix to avoid all the errors :) We should add it back ASAP after the upcoming release |
I believe it should be added again, as this PR's focused on fixing the errors. 🙂 |
It seems that as long as we add again |
Re-creating the PR would be easier, though, as all PRs will have that action and fail. |
@Panquesito7 I can work on this during the weekend. Based on @Snailedlt's comment below, I thought we would work on this after the release.
|
@ConX |
Double check these details before you open a PR
Features
According to the
git-auto-commit-action
README, the ref should be specified in the preceding action/checkout@v3.If successful, this PR closes #1715
Notes
The two aarch64 icon files that have been updated were to test whether the workflow succeeds.