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

Bugfix: Fix optimize_icons workflow error on PRs #1718

Closed
wants to merge 14 commits into from
Closed

Bugfix: Fix optimize_icons workflow error on PRs #1718

wants to merge 14 commits into from

Conversation

ConX
Copy link
Contributor

@ConX ConX commented Mar 28, 2023

Double check these details before you open a PR

  • PR does not match another non-stale PR currently opened

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.

@lunatic-fox
Copy link
Contributor

Thank you to open this PR! 🚀
Unfortunately, it seems that still not working properly, but I'll try something else on the next commit.

@lunatic-fox
Copy link
Contributor

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. 🤔

@ConX
Copy link
Contributor Author

ConX commented Mar 28, 2023

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:

  1. Edit the PULL_REQUEST_TEMPLATE for new icons to include a checkbox to ask the contributor to enable `Allow edits by maintainers".
  2. Make the SVG optimization only part of the merge instead of being triggered at each new PR or PR update. The way I think this might work is to run right after a merge on our develop branch, where there shouldn't be any permission issue.

@ConX
Copy link
Contributor Author

ConX commented Mar 28, 2023

Thank you to open this PR! 🚀 Unfortunately, it seems that still not working properly, but I'll try something else on the next commit.

The changes here are not getting executed right now since this hasn't been merged with the develop branch yet. I think we should merge it and check with existing/failing PRs.

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.

@ConX
Copy link
Contributor Author

ConX commented Mar 30, 2023

Based on this this issue comment from the author of the git-auto-commit-action, I switched the listening even to pull_request_target, which should run when the PR is merged and executed on the base branch (which in our case should be develop).

Is it worth merging to see if it works?

Copy link
Contributor

@lunatic-fox lunatic-fox left a 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 to pull_request_target, which should run when the PR is merged and executed on the base branch (which in our case should be develop).

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.

Copy link
Collaborator

@Snailedlt Snailedlt left a 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?

@lunatic-fox lunatic-fox self-requested a review March 30, 2023 09:04
@lunatic-fox
Copy link
Contributor

Hmm @ConX, after reading a little Keeping your GitHub Actions and workflows secure, I'm wondering if the trigger is pull_request_target and develop is the target branch, this might cause the optimized icons of pr_branch to be committed to develop and that's for sure is a problem.

Also, does this workflow run when merging to madter as well, or just to develop?

@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 workflow_run, that was mentioned before in other comment by @Snailedlt.

@Snailedlt
Copy link
Collaborator

Yeah, I think we should go for the preflight workflow option with workflow_run.
This is how we fixed the in-develop labeler: #1410

@ConX
Copy link
Contributor Author

ConX commented Mar 31, 2023

I'll read the article this weekend. For now I think we should try this way, with workflow_run, that was mentioned before in other comment by @Snailedlt.

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 workflow_run approach seems a better option. Should we wait to implement this after the #1410 is merged, and re-use the same preflight as the triggering workflows in workflow_run?

@Snailedlt
Copy link
Collaborator

@ConX No we shouldn't wait.
The other PR won't take effect until it's merged into master, and iirc will break some stuff before it takes effect.
Therefore we're waiting until release to merge it into develop, so that we have minimal time with a workflow that foesn't work.

This PR however shouldn't break anything, so we can merge it into develop without issues :)

Copy link
Member

@Panquesito7 Panquesito7 left a 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.

@ConX
Copy link
Contributor Author

ConX commented May 3, 2023

Looks like there are merge conflicts. Please fix them.

@Panquesito7 The workflow updated here optimize_icons.yml appears to have been deleted by #1724. Should it be re-added, or should we simply close this PR?

@Snailedlt
Copy link
Collaborator

Looks like there are merge conflicts. Please fix them.

@Panquesito7 The workflow updated here optimize_icons.yml appears to have been deleted by #1724. Should it be re-added, or should we simply close this PR?

@ConX Yes, that was just a temp fix to avoid all the errors :) We should add it back ASAP after the upcoming release

@Panquesito7
Copy link
Member

Looks like there are merge conflicts. Please fix them.

@Panquesito7 The workflow updated here optimize_icons.yml appears to have been deleted by #1724. Should it be re-added, or should we simply close this PR?

I believe it should be added again, as this PR's focused on fixing the errors. 🙂

@lunatic-fox
Copy link
Contributor

It seems that as long as we add again optimize_icons.yml to develop this branch will stop conflicting. 🙂

@Panquesito7
Copy link
Member

Panquesito7 commented May 13, 2023

Re-creating the PR would be easier, though, as all PRs will have that action and fail.
EDIT: @ConX, do you have the time for this, or should we let someone else do this? 🤔

@ConX
Copy link
Contributor Author

ConX commented May 13, 2023

EDIT: @ConX, do you have the time for this, or should we let someone else do this? 🤔

@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 Yes, that was just a temp fix to avoid all the errors :) We should add it back ASAP after the upcoming release

@Snailedlt
Copy link
Collaborator

@ConX
Yeah, let's do this after the release :)

@ConX ConX closed this by deleting the head repository May 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants