Adds image compression action on pull requests

[claudenirmf]

Adds image compression action. This action is to be triggered on pull requests.

NOTICE: there is a discussion on this action's repo about it not working in pull requests coming from forked repos (see this issue discussion). The developers have disabled the action in these cases, which may require an additional PR on the original repo to trigger the action and actually compress the image files. The disabling of the action avoids silent error on the action's log.

I have submitted a question to the developers for more clarification, but we could merge this PR in the meantime.

Closes #11.

[claudenirmf]

Considering these instructions, I would consider having some staging or development branch from which we merge changes into master. Having a separated master branch should allow us running the action internally and may make it easier for us to version the repository through releases.

I would not consider creating a GitHub token with elevated permissions because this may introduce unnecessary vulnerabilities, e.g., from dependabot-like PRs.

[tgoprince]

I support your staging branch solution.

Could you just clarify how often do you envision merging the staging branch with the master branch?
I don't see a need to version this dataset, so I'm assuming it would follow every PR from a forked repository.

We could automate the creation of this internal PR with something like this:

https://github.com/marketplace/actions/create-pull-request

[tgoprince]

I tested this on action on #15.

It provides some nice feedback on the PR and it parses all images in the repository, but only commits those that have actually been compressed.

Overall, this is a very good script for our dataset.

Good job @claudenirmf!

[claudenirmf]

Maybe we won't need to "version" the repo, but creating releases may be necessary to ease the reproducibility of published experiments. Zenodo could also be used here.

For the staging branch, I would expect a new PR from it into the master for every PR coming from a forked repo. I like your idea of automating this staging/pr step but I don't know if we could have problems if two PRs were to be created in a very short period of time. The second automated PR could interfere with the first, I don't know.

I will try to add the action you suggested before merging this PR. Thanks for the feedback!