It took a few attempts to find a solution to get a version # to tag the releases with. In my case I have a VERSION file containing the version number, such as 0.1.0. This solution should be applicable even if the desired version is stored elsewhere so long as it can be accessed from a bash shell.

The first step gets the version via a run command and sets the output. See the [documentation for

When testing in a matrix, uploads often fail after the first one. I'm testing against different versions of Python, and I only need to upload the coverage information once, by including

if: matrix.python-version == 3.8

in the codecov job. It took me a while to figure this out, so maybe it is nice to include this in the readme.

Hi! I can't find any clear documentation about the asset_content_type field -- what the options are, what this does etc.

If there is some documentation in another place, maybe it'd be worth linking to it in the readme?

Sorry if there's been an existing issue for this -- I couldn't find any.

Summary
Documentation for handling nested projects is out of date/incorrect.

The README example for the working-directory option shows that the folder structure below should work with a configuration that sets working-directory: e2e. This is not the case.

File structure:

repo/
  app/
  e2e/
    cypress
    

Currently certain PR's coming from forks result in the action running in the context of the fork, which means it can't post a comment or a PR review to the PR/issue.

Possible workarounds:

1. Report the size table back using a Status Check
   • Not sure if GitHub's UI will handle