Overly restrictive tar-file requirements (leading `./` needed)

Hey,

I'm investigating a very specific issue using deploy-pages, and I think I've narrowed it down to a 100% repro. I'm using a custom build setup with a static page generator. Due to some build process changes I ended up moving from packaging loose files to directly building the tar archive (i.e., replacing upload-pages-artifact). That change broke this action. After a lot of testing; I've found that the two commands below end up bisecting the behavior. In practice, the latter archive is generated by a build tool without using the tar command.

This works:

tar cvf "artifact.tar" ./*

While this fails:

tar cvf "artifact.tar" *

In a hypothetical situation where we're only tarring an index.html the first command creates the tar file [./index.html], whereas the latter is simply [index.html]. Not handling this seems like a bug, but at a minimum it should probably be documented on this action if it's intentionally required. As far as I can tell, on my specific version of tar, these two archives extract identically regardless of cwd, -C, etc.

This is the error message when using the latter format:

Artifact could not be deployed. Please ensure the content does not contain any hard links, symlinks and total size is less than 10GB.

The same behavior can also be observed by adding --xform s:'./':: to the working command, which indicates that this is indeed a result of the directory structure inside the tar.

The tar used for testing:

tar (GNU tar) 1.34

Happy to supply any more info as necessary.

No source file or test is named. First reproduce the behavior with the two tar commands on GNU tar 1.34 and inspect how deploy-pages validates archive paths. Done means archives containing entries such as index.html are accepted like ./index.html archives, or the required format is documented clearly.