What problem would this feature solve?

I have images under dot directory (like .vuepress ) on my project.
But it seems to be ignored on compress action.

Describe the solution you’d like to see

Includes dot directory on compress target.
It could be achieved by enable dot: true option for glob module.

Describe alternatives you’ve considered

• Add option for including dot directory or not.

Additional context

• Target Directory: https://github.com/shufo/shufo.dev/tree/master/docs/.vuepress/public/assets/img/uploads
• Invoked Action: https://github.com/shufo/shufo.dev/actions/runs/325394357

It appears that the default settings are not lossless. I ran this action on a private repo with some already losslessly optimized images (via ImageOptim for MacOS) and it reduced the filesizes and quality of most of the images. In the 'image-actions' settings it says the default settings are:

jpeg:
  quality: 80
png:
  quality: 80

if that is indeed lossless then what would changing those numbers to 100 do?

According to: http://sharp.pixelplumbing.com/en/stable/api-output/#jpeg and http://sharp.pixelplumbing.com/en/stable/api-output/#png the lossless setting is off by default.

Is the huge building time known and intentional? I couldn't manage to get a build briefer than 10 minutes in GitHub Actions.

Does this work just like imgbot? It scans the base repo and opens a pr with the images all optimized? Did I get that correctly?

@benschwarz looks like there's a problem with the new compressOnly and pull request option we recently added.

I've just done some testing on my own repo and it compressed, and opened a PR with all the changed files as expected. Unfortunately however nearly all the files grew in size! Think these are images I'd optimised outside of calibre action so guessing that optimised them a bit differently/more efficiently. Example run here.

I was under the (perhaps mistaken!) belief that the image files would only be overwritten if they were smaller but guess that's not the case? If so we need to rethink this, as the create pull request sweeps up ALL files that have been changed, whether bigger or smaller, and if there are any then creates a pull request.

We should probably remove the advice to use create-pull-request from the README for now to prevent people increasing images sizes.

it is possible to ignore PNG and PNG?

Adding SVGO support to optimize SVG files would be great! Warning that SVGO can break SVG font files however.

Hi, I have a question and want to your opinion.

Now I'm using the Amplify Console by AWS. This is executed related to the pull request and start the AWS environment. So that is behaving as the Github integration on PR.

In the Image Actions, it automatically add the commit by bot. However, somehow it won't end integrate progress only when this commit.

The strange thing is that even though the operation is completed successfully on the AWS console screen, Actually it's still displayed as in progress on Github.

I can't isolate that the problem point is Github platform, AWS or this.

If you know anything, please response.
If you no idea, would you close this issue. no problem :)

Thank you.

Hi, 👋

Thanks for making this GitHub action. I'm trying this out to use in our organization.

I was looking for a way to turn on progressive jpeg because I think it'll have a comeback with http2.

While webp can give the smallest of file size, it doesn't support progressive or interlaced mode by jpeg. Where you can just send 10 to 20% of the file and your users visually see the whole image.

I believe it's supported by the dependency under the hood it's just a matter of exposing the option? Let me know if this is something we can add, I can help with a PR if needed.

#37 (comment)

I stumbled in here looking for GIF support, which is offered by another GitHub Action, but I wasn't looking too add another monthly subscription to use their underlying API service (only 25MB on the free tier).

If this were to be attempted at all, using gifsicle would likely be the path forward. It's what powers GIF optimization in ImageOptim, Gifski, and soon probably Kap too.

This action fails on my repo because one of the urls to an image is actually a symlink. Here's the error:

(node:1) UnhandledPromiseRejectionWarning: Error: ENOENT: no such file or directory, stat '/github/workspace/public/apple-touch-icon.png'
(node:1) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:1) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Maybe a quick fix is to have this action ignore symlinks?

I think writing "near-lossless compression" is a bit misleading. Compression can either be lossless or lossy, there is no "near-lossless", that's called lossy compression. It seems like the defaults are lossy, so I would either clarify that "near lossless-compression" is actually "high quality lossy compression" or something similar.

What do you think?

Not sure if this is something to do with my images but having an issue where this action is failing with ##[error]Docker run failed with exit code 78

We don't often add images to PRs so I'm not sure how typical this type of failure is.

In the past, the action has definitely worked as anticipated without failing.

Thanks for maintaining this! ❤️

Just started getting this a few hours ago, no config changes were done.

(node:1) UnhandledPromiseRejectionWarning: TypeError: githubEvent is not a function
    at main (/usr/local/src/image-actions/entrypoint.js:26:25)
    at Object.<anonymous> (/usr/local/src/image-actions/entrypoint.js:40:1)
    at Module._compile (internal/modules/cjs/loader.js:1137:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1157:10)
    at Module.load (internal/modules/cjs/loader.js:985:32)
    at Function.Module._load (internal/modules/cjs/loader.js:878:14)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:71:12)
    at internal/main/run_main_module.js:17:47

name: Compress images

on:
  pull_request:
    paths:
      - '**.jpg'
      - '**.png'
      - '**.webp'
jobs:
  build:
    name: calibreapp/image-actions
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repo
        uses: actions/checkout@v1

      - name: Compress Images
        uses: calibreapp/[email protected]
        with:
          githubToken: ${{ secrets.github_token }}
          jpegQuality: "80"
          pngQuality: "80"
          webpQuality: "80"
          ignorePaths: "node_modules/**,build"

The above is our GitHub Action.

When we create a pull request, a number of files compressed by the action. However, if we make any changes to the pull request with the compressed assets a subset of the compressed assets are re-compressed.

I would have assumed that the compressed file could not be compressed again (through the same algorithm) but that is what appears to be happening.

PR 1: quality 80

PR hugovk/python-logos#1 adds the default workflow in .github/workflows/calibreapp-image-actions.yml from:

https://github.com/calibreapp/image-actions#how-to-add-this-to-your-repository

name: Compress images
on: pull_request
jobs:
  build:
    name: calibreapp/image-actions
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@master
      - name: calibreapp/image-actions
        uses: docker://calibreapp/github-image-actions
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

PR 2: quality 100

PR hugovk/python-logos#2 is the same, but with this config in .github/calibre/image-actions.yml:

jpeg:
  quality: 100
png:
  quality: 100
webp:
  quality: 100

And the action read in the config:

->> Using config: {"jpeg":{"quality":100},"png":{"quality":100},"webp":{"quality":100},"ignorePaths":["node_modules/**"]}

https://github.com/hugovk/python-logos/runs/295767221#step:4:7

However, the images in both PRs are binary identical:

This is surprising, should the images with 100 quality be lossless? I'd expect at least some difference.

Thanks!

Based on https://github.com/trustwallet/assets/runs/221998657

Is there a way to ignore this error and continue the job and compress all the images? it sounds like it silently fail and does not produce any compressed images

Also, is there a way to know which images causes this issue? I can try to delete it to continue

Is it possible to make this work for a build action? As I would find this very useful for things like static page blogs (that get built on GitHub Actions), where having compressed images is a plus, but not always is simple to compress images prior to committing, and this would be able to solve that issue...

I don't know how to configurate this action to recognize my webps images (it works well on all the others images).
I have this output in github action :

- Processing: /github/workspace/docs/images/background.webp
[Error: Input file contains unsupported image format]

Any clue ?

Running image actions on an existing repository, I received this error:

/usr/local/src/image-actions/src/constants.js:15
const IGNORE_PATHS = process.env["INPUT_IGNOREPATHS"].split(",") || ["node_modules/**"];
                                                      ^

TypeError: Cannot read property 'split' of undefined
    at Object.<anonymous> (/usr/local/src/image-actions/src/constants.js:15:55)
    at Module._compile (internal/modules/cjs/loader.js:816:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:827:10)
    at Module.load (internal/modules/cjs/loader.js:685:32)
    at Function.Module._load (internal/modules/cjs/loader.js:620:12)
    at Module.require (internal/modules/cjs/loader.js:723:19)
    at require (internal/modules/cjs/helpers.js:14:16)
    at Object.<anonymous> (/usr/local/src/image-actions/entrypoint.js:3:45)
    at Module._compile (internal/modules/cjs/loader.js:816:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:827:10)
##[error]Docker run failed with exit code 1

This is due to the change in #29

What problem would this feature solve?

Currently, the only output we can get from the action is the steps.calibre.outputs.markdown which uses either the pr-comment.md or the inline-pr-comment-with-diff.md. In certain cases, this template is too big to be used as an environment variables on the Actions runner causing an Error: Argument list too long error.

Describe the solution you’d like to see

I would like to see something like a pr-comment-minimal.md where you only show the comments and numbers without the big table with all the images and changes that happened.
eg:

Images automagically compressed by Calibre's image-actions ✨

Compression reduced images by <%- overallPercentageSaved %>%, saving <%- overallBytesSaved %>.

<% if(unoptimisedImages.length) { -%> <%- unoptimisedImages.length %> <%- unoptimisedImages.length > 1 ? 'images' : 'image' %> did not require optimisation. <% } %>

Describe alternatives you’ve considered

Alternative is to not use the output of this action on follow up actions (like the create-pull-request one).

Additional context

N/A

What problem would this feature solve?

I would like to have an option to keep metadata (EXIF data) on my images after optimising.

Describe the solution you’d like to see

An other option to keep or delete metadata.

Describe alternatives you’ve considered

Well, not use the action, I guess ? I really like it otherwise, so I hope I will be able to keep it, but I need to keep metadata for my images. I know the Sharp image processing used underneath has an option for that, I guess the action coule let us use it ?

Additional context

I'm using metadata to display dates and locations for photos I post on my website.

What problem would this feature solve?

I've made a workflow to convert all images to WEBP, and noticed we can futher compress those images to get AVIF levels of compression. However, we do everything based on commit and pull.

So when developer adds some images in their commit, it will be converted to webp and then compressed. However image-actions doesn't seem to work in this regard. I haven't been able to find anything where it can do this based on commit level.

If possible, i would love to see it being able to scan the current files, compress them, and leave it be, so that i can push them in the workflow so that everything is converted and compressed.

Basicly an option to not make a pullrequest and just compress and leave them be withoud breaking.

Not sure if you guys posted anywhere, but I could not find out the pricing attached to this github action? Thanks!

It would be good to specify the file path for triggering the action.

Right now, it is like this:

name: Compress images
on: pull_request

Propose:

name: Compress images
on:
  pull_request:
    paths:
    - '**.jpeg'
    - '**.png'
    - '**.jpg'
    - '**.webp'

First up, thanks for the excellent GitHub action!

However, I was surprised recently to find this doesn't work on pull requests from forks and fails silently, with only this error message hidden in the GitHub action logs to indicate it didn't complete:

    - Processing: /github/workspace/src/static/images/test.png
->> Generating markdown…
->> Committing files…
	 *  Head SHA: 41a31c3fc57433f287e5091d538e79504bb4310c
	 *  Tree 5849f57c3558964e83b965ed66b32332a8e077ac
	 *  Converting images to blobs…
(node:1) UnhandledPromiseRejectionWarning: HttpError: Resource not accessible by integration
    at response.text.then.message (/usr/local/src/image-actions/node_modules/@octokit/request/lib/request.js:56:27)
    at processTicksAndRejections (internal/process/task_queues.js:86:5)
(node:1) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:1) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Digging into GitHub actions I understand why – because upstream repos don't have access to change downstream branches – and on second look, I did find this mentioned on the README:

The GITHUB_TOKEN secret is automatically generated by GitHub. This automatic token is scoped only to the repository that is currently running the action.

However this was not clear to me, and imagine it isn't to others either and accepting pull requests from forks is really what GitHub is all about.

I've a few suggestions to improve this:

Making people more aware of this restriction

First of all I would suggest expanding on that line in the README to explain what it means to forks. I'm happy to throw in a suggested pull request with wording for this if you'd like?

We could also add advice to only run this GitHub action on pull requests from and to the same repo, as pointless run other than that so a waste of time and compute. Not sure exactly how to do this but happy to look into the appropriate if: line to add to the suggested .yml config if you want?

How can we fix this?

I presume getting forked repos to implement a Personal Access Token would work, but not sure that's a great idea to be honest. It only works for regular contributors who will go to this effort of setting up a PAT – and regular contributors might as well work off of the main repo.

A better option might be to allow the action to also run on pushes. Then could run it on master after the PR has been approved. Ideally that would allow the option to commit directly to the push branch (master in this case - for those that are crazy enough to want that) or to open a new pull request with the compressed images after merging (probably better!).

Alternatively changing the action to only do the compression, and not handle the commit, would allow the Checkout GitHub Action to handle the commit (though this does an extra config line to checkout the correct head branch), or something like the Create Pull Request GitHub Action to create a new pull request, after merging pull requests from forks. Might mean less code for you to maintain, more flexibility, but at the cost of more complicated workflow set up. Or alternatively make this optional for those (like me!) that want the power of handling the commit differently. Probably need to do that to maintain backwards compatibility to be honest.

Anyway, quite a lot in there, so maybe better split into a number of issues but thought best to start a discussion first so let me know your thoughts.

I added:

name: Compress images
on: pull_request
jobs:
  build:
    name: calibreapp/image-actions
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@master
      - name: calibreapp/image-actions
        uses: docker://calibreapp/github-image-actions
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }

as .github/workflows/calibreapp-image-actions.yml to a private repo. The bottom of the README for this project says:

This action requires a GITHUB_TOKEN secret so that it has access to commit the optimised images to your repository.

Where do you create that GITHUB_TOKEN secret though? Or is it done automatically? I see you can add Secrets via the Settings > Secrets menu, but do I need to enter a specific name? This part isn't very clear....

One feedback that I got is whether this github action is potentially going to re-compress the already-compressed images.

I am curious about what are your thoughts on it.

Would be awesome if there was a option to resize images as well.

Just noticed today that the image-action seems not compressing the jpeg file (changing the file extension to jpg works for me)

/kind bug

First thank you for this great action; it's very useful!

I am facing an issue in trying to enable this action in a project with a large set of existing images (1000+). The first PR using the action generates a lot of GitHub API calls which hits API throttling limits (the error is silently swallowed btw).

https://github.com/microsoft/pxt-microbit/commit/89983dafb205dfbf627bbc9f066b58436196fa6c/checks?check_suite_id=321921856#step:4:918

Is there a way to run the image optimization locally to "bootstrap" an existing repository?

Thank you for creating this well-documented action! 🙌

Also, please forgive me if I missed any documentation or settings that would solve what I'm requesting. 😅

What problem would this feature solve?

It looks like this action will optimize all images in the repo that match any selected paths. If that is true, I'd love the ability to be able to only optimize images that are part of the commit that triggered the workflow. This would speed up a potentially long process and target only changed images.

We have a very large directory of images that takes up to 5 hours to compress, but if we know that the existing images are already compressed, it'd be great to only optimize images that are added or updated.

Describe the solution you’d like to see

An input parameter that allows you to select targeting only images that are part of the commit that triggered the workflow. This would likely only be applicable to pull_request and push events.

If the input parameter is set, the action would retrieve the list of changed files and find any image files. If there are changed image files, those images will be compressed.

This doesn't seem to work well on a large repo (we have many, many images in our repo for devopsdays/devopsdays-web. When we run the action, it eventually errors at the end with:

	 *  Head SHA: cdf0db10952ecef99e62678e452c9d6bd7dc014b
	 *  Tree 8a59b30c851ab4107af8c85f0d66fae9d2892257
	 *  Converting images to blobs…
(node:1) UnhandledPromiseRejectionWarning: HttpError: API rate limit exceeded for installation ID 1908306.
    at response.text.then.message (/usr/local/src/image-actions/node_modules/@octokit/request/lib/request.js:56:27)
    at processTicksAndRejections (internal/process/task_queues.js:86:5)
(node:1) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:1) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

https://github.com/devopsdays/devopsdays-web/pull/8274/checks?check_run_id=222210418#step:4:7317 for reference. Or https://github.com/devopsdays/devopsdays-web/runs/222210418

TinyPNG.com seems to produce much smaller images (40-60% smaller) with no noticeable loss in quality as far as my untrained eye can see. Any ideas how they do this? As I do really like this integration in GitHub Actions but at the moment I end up using this for the immediate effect and then going back and TinyPNG-ing the images later when I have time.

Any way to look at images and see what compression ratio they are using?
Or are they stripping meta-data that Calibre is not?
Or something else?

Would love it, it there was a simple config change to get same savings and save me this effort!

Agree this would be useful. And agree currently it does all files each time - that's working as intended at the moment btw, rather than a bug per se, though can understand why it's not what some would want.

BTW I think this should be optional, so can have some runs use this new functionality if/when it's added (maybe "on" by default for all pull request runs?) but still have the option of doing a full run to use the original (slower) full run (e.g. a timed run could be run weekly to compress everything for example in case anything was missed).

Here's how I've got the list of files for another project btw, using bash rather than JavaScript, but might be helpful as a starting off point:

    # If this is part of pull request then get list of files as those changed
    # Uses similar logic to GitHub Super Linter (https://github.com/github/super-linter/blob/master/lib/functions/buildFileList.sh)
    # First checkout main to get list of differences
    git pull --quiet
    git checkout main
    # Then get the changes, for the files needed:
    CHANGED_FILES=$(git diff --name-only "main...${COMMIT_SHA}" --diff-filter=d | egrep -i '\.jpg|\.jpeg|\.png|\.webp'
    # Then back to the pull request branch
    git checkout --progress --force "${COMMIT_SHA}"

Originally posted by @bazzadp in #92 (comment)

Describe the bug

When a PR is closed and then reopened, the action job fails with Error: Check run has action reopened . Wants: synchronize or opened

How To Reproduce

Steps to reproduce the behavior:

1. Open a PR
2. Wait for a job to finish
3. Close the PR and then reopen it
4. Job fails. See error

Expected behaviour

The jobs does not fail (either do not run or run and be skipped)

Additional context

Config:

name: Compress images
on: pull_request
jobs:
  build:
    name: calibreapp/image-actions
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@master
      - name: calibreapp/image-actions
        uses: docker://calibreapp/github-image-actions
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Relevant code seems to be entrypoint.js#L27

On web.dev we never need images larger than 1600px. I frequently have to ask our contributors to resize their images (in order to keep the repository size down). Are you open to adding image resizing to image-actions or should we look for other solutions?

Edit: We never need images within our main content to be more than 1600px. There are a few exceptions we'd need to specify but I can share more details later.

Even after the action has been merged into master, subsequent PR's fail silently when processing:

    - Processing: /github/workspace/static/videos/motion/motion-style-expressive.jpg
    - Processing: /github/workspace/static/videos/motion/motion-style-insitu.jpg
->> Generating markdown…
->> Committing files…
	 *  Head SHA: c7d4a5f6eb23c468850cc77dbc13a369e0e07d1d
	 *  Tree 2737fa5f107a598c0fc1d6a196d8725e5223fd2f
	 *  Converting images to blobs…
(node:1) UnhandledPromiseRejectionWarning: HttpError: Resource not accessible by integration
    at response.text.then.message (/usr/local/src/image-actions/node_modules/@octokit/request/lib/request.js:56:27)
    at processTicksAndRejections (internal/process/task_queues.js:86:5)
(node:1) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:1) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Example run

What:

allow flags to exit as failure if the found images compress at a higher level than the declared threshold, thus indicating that the committed images were not pre-optimized.

Why:

• large images in git will inflate the total size of the repository and make cloning slow
• preventing large images from being stored in a git repo at the PR level

How:

• add an input flag run-as-test (or better wording) which exists with a failure signal if the resulting compression is bigger than the defined quality setting
• the resulting comment text should also reflect the language of "testing" vs. "results", e.g.

some images did not match the compression requirements:
| Filename        | Variance |
| --------------- | --------- |
| /path/file.jpg  | 20%       |

Currently image-actions run on all pull-requests actions, among which, the majority triggers are pushes that have nothing to do with images. Is it possible to filter down the commit to see if there are actually images involved before triggering the action?

Thanks for the good work!

I have a repository with images tracked in git-lfs.
My .gitattributes:

*.jpg filter=lfs diff=lfs merge=lfs -text
*.png filter=lfs diff=lfs merge=lfs -text

So my configuration for github's action checkout step is:

- name: Checkout Repo
        uses: actions/checkout@master
        with:
          lfs: true # NOTE this line

Calibreapp optimizes images well but instead of committing optimized images to git-lfs it commits them directly to git repository (by creating binary files instead of pointers)

I suspect the problem is here:

So I cannot use this action with my current setup :(
Do you plan to support git-lfs repositories?

It'd be awesome if this would work in a non-pull-request workflow, e.g. for simple pushes to master. Just tried it, didn't work.

Describe the bug

I'm working on a repo that already contains an animated webp file. Calibre keeps trying to optimize the animation out of the image when I make PRs. From the documentation it looks like I should be able to add ignorePaths with a comma-separated string of globs to the workflow in order to ignore the webp, but I can't get it to work. I'm pretty new to GH Actions so my apologies if there's an obvious solution here, but so far I'm feeling pretty stuck. Here's what I've tried.

How To Reproduce

1. Use ignorePaths to explicitly ignore webp paths:

name: Optimize Images
on: pull_request
jobs:
  build:
    name: calibreapp/image-actions
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Branch
        uses: actions/checkout@master
      - name: Compress Images
        uses: calibreapp/image-actions@master
        with:
          ignorePaths: '**.webp'
          githubToken: ${{ secrets.GITHUB_TOKEN }}

2. Try explicitly setting INPUT_IGNOREPATHS:

name: Optimize Images
on: pull_request
jobs:
  build:
    name: calibreapp/image-actions
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Branch
        uses: actions/checkout@master
      - name: Compress Images
        uses: calibreapp/image-actions@master
        with:
          githubToken: ${{ secrets.GITHUB_TOKEN }}
        env:
          INPUT_IGNOREPATHS: '**.webp'

3. Download and build the repo, run INPUT_IGNOREPATHS="**.webp" npm run test

Expected behaviour

In the first 2 cases I can see from logging that ignorePaths remains the default value of [node_modules/**]. On the third test ignorePaths updates successfully, but the test webp still gets compressed. Am I doing something wrong here, or is this a bug?

I'm using secrets.GITHUB_TOKEN to push nuget package to nuget.pkg.github.com. Pretty frequently I get below error. Once in a while it is successful. Can you please investigate / suggest a workaround?

pushnuget.ps1.txt

Error:

Run .\pushnuget src\out ***
Pushing MonoTorrentTestApp.1.0.52.nupkg to 'https://nuget.pkg.github.com/marketly'...
  PUT https://nuget.pkg.github.com/marketly/
WARNING: Resource not accessible by integration
  Forbidden https://nuget.pkg.github.com/marketly/ 297ms
Response status code does not indicate success: 403 (Forbidden).
##[error]Process completed with exit code 1.

Was just reading through the documentation which is clearly oriented towards pull-request workflows—could you help advise me on how I might use this action (or modify it) to just compress & commit images on every push to master?

For folks using a web CMS like Netlify CMS or Forestry to publish a solo blog, it's more typical to just commit every change to master, so this workflow would be pretty fantastic if it could run automatically without needing to introduce pull requests.

Thanks for your time and consideration!

At the moment image-actions runs only when you've updated a pull request. Images are optimised and committed inline.
In most cases, this works quite well, but there are some drawbacks to this approach:

• The next time you push to your PR, you'll need to pull first (because image-actions has produced a new commit)
• By adding a commit, some test suites will run (again), clogging up builds for a longer duration
• If you're displeased with the image compression (or some other issue), you're not able to choose if you want the changes or not. This isn't something I've faced personally, but either way the fix (remove the commit and then turn off image actions) isn't very straightforward and feels like busy work.

By using GitHub Actions scheduler, image-actions could:

• Be run periodically (as often as you like - daily, weekly, monthly, etc)
• If there's optimisations, a pull request could be created -- rather than interrupting WIP (similar to dependabot or other tools)

This issue stands as a mark of intent to implement. If anyone has the bandwidth to help, please let me know or submit a PR 🏆

I asked on twitter about some support and was directed here. Hopefully this is relatively trivial and can be addressed really quickly.

I am looking to use image actions to check our codebase on a weekly basis for uncompressed assets, and also "on demand" if we're doing a lot of work with our images. The challenge Im facing is that I'm unable to get Image Actions to create a PR once it has checked the images. I can see that its correctly traversing the code, however base but it is skipping the "Create New Pull Request If Needed" step.

Our branching strategy does not allow direct commits to master, could this be related?

Here's my config:

name: Compress Images
on:
  workflow_dispatch:
  schedule:
   # run weekly every Sunday night
    - cron: '0 23 * * SUN'
jobs:
  build:
    name: calibreapp/image-actions
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repo
        uses: actions/checkout@master
      - name: Compress Images
        uses: calibreapp/image-actions@master
        with:
          ignorePaths: 'node_modules/**'
          jpegQuality: '80'
          jpegProgressive: false
          pngQuality: '80'
          webpQuality: '80'
          githubToken: ${{ secrets.github_token }}
          compressOnly: true
      - name: Create New Pull Request If Needed
        if: steps.calibre.outputs.markdown != ''
        uses: peter-evans/create-pull-request@master
        with:
          title: Compressed Images Weekly
          branch-suffix: timestamp
          commit-message: Automated Weekly Image Compression
          body: ${{ steps.calibre.outputs.markdown }}

and a sample part of the output

    - Processing: /github/workspace/public/themes/modernist/4px_solid_border.png config={"quality":80} output={"format":"png","width":1,"height":4,"channels":4,"premultiplied":false,"size":94}
    - Processing: /github/workspace/public/themes/modernist/border_emphasised_print.png config={"quality":80} output={"format":"png","width":778,"height":4,"channels":4,"premultiplied":false,"size":139}
    - Processing: /github/workspace/public/themes/modernist/border_emphasised.png config={"quality":80} output={"format":"png","width":764,"height":4,"channels":4,"premultiplied":false,"size":137}
    - Processing: /github/workspace/public/themes/modernist/border_print.png config={"quality":80} output={"format":"png","width":778,"height":4,"channels":4,"premultiplied":false,"size":135}
    - Processing: /github/workspace/public/themes/modernist/border.png config={"quality":80} output={"format":"png","width":764,"height":4,"channels":4,"premultiplied":false,"size":136}
    - Processing: /github/workspace/public/themes/modernist/dotted_border.png config={"quality":80} output={"format":"png","width":5,"height":1,"channels":4,"premultiplied":false,"size":95}
->> Generating markdown…
->> Using config: {"jpeg":{"quality":80,"progressive":false},"png":{"quality":80},"webp":{"quality":80},"ignorePaths":["node_modules/**","spec/fixtures/files/**","compartments/loader/spec/test_app/**"],"compressOnly":true}
Am I missing something here? I know we have a number of uncompressed images in our code.

Thank you.

Describe the bug

When it tries to commit the changes, it fails with an UnhandledPromiseRejectionWarning

How To Reproduce

Steps to reproduce the behavior:

1. Go to logs
2. Scroll down to 'Compress images', and then 'Committing Files...'
3. See error:

UnhandledPromiseRejectionWarning: HttpError: request to https://api.github.com/repos/[my username]/[my repo]/git/blobs failed, reason: read ECONNRESET
    at /usr/local/src/image-actions/node_modules/@octokit/request/lib/request.js:94:13
    at processTicksAndRejections (internal/process/task_queues.js:97:5)

Expected behaviour

Should add a commit to the PR 🙃

Screenshots

Additional context

Also note that the repo is private; however, yesterday was working nicely.
When I click in the URL that it provides, it shows a 404 page

Hi there 👋

First of all, thank you for creating this Github action!

I've tried to add the configuration as shown in the README:

name: Compress images
on: 
  pull_request:
    paths:
      - '**.jpg'
      - '**.png'
jobs:
  build:
    name: calibreapp/image-actions
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repo
        uses: actions/checkout@master

      - name: Compress Images
        uses: calibreapp/image-actions@master
        with:
          githubToken: ${{ secrets.GITHUB_TOKEN }}

In the "Compress images" job, it first runs fine and all images get compressed. Then, at the end, I get the following error:

Converting images to blobs…
(node:1) UnhandledPromiseRejectionWarning: HttpError: Resource not accessible by integration
    at response.text.then.message (/usr/local/src/image-actions/node_modules/@octokit/request/lib/request.js:56:27)
    at processTicksAndRejections (internal/process/task_queues.js:86:5)
(node:1) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:1) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Any idea how I could fix this?