Better support for multiple html files #400
Description
The problem
Currently this action supports mono repos by treating all index.html and index-top.html files specially. When they are copied to S3 they are set to not be cached. And additionally when the "topBranch" feature is used, the index-top.html files are copied and renamed to index-[branch].html.
To do a release of a project with a single html file the repository needs a script which copies/version/[version]/index-top.html to /index.html. So then with a mono repo that needs to release all of its subfolders this script has to be updated to also copy all of the index-top.html files from the subfolders to to the production folder. For example /version/[version]/subfolder/index-top.html needs to be copied to /subfolder/index.html.
These scripts so far do not look at the all of the files in the /version/[version] to figure out what to copy. Looking at these files would be probably inefficient because I don't think S3 has good support for finding the list of files which match certain patterns.
This existing approach means there are two mechanisms for identifying which files to copy. The topBranch code in this action repository uses a pattern to find the files, and the actual release scripts use a hard coded list of files. This leads to issues at the critical final release step.
Additionally some projects use multiple top level html files which are not named index.html. For example admin.html or author.html. These files are not currently supported by the action, and will not be deployed with the right cache headers.
The solution
My recommendation to improve this is to deploy the list of html files which should be copied with the other deployed files. This list could then be used both by this action when doing a topBranch copy, and by the release script.
The release scripts would now have to be more complicated because they would need to first download this file list from S3 and then run the commands to copy of these files. Because of this it would probably be best to expand this action to support doing the release too not just the deploy.
Requiring this action to do the release shouldn't be the point though. We still want to allow other tools outside of GitHub to manage the release process. For example an "release" SPA that can be hosted on the same site. This SPA could use Cognito to authenticae and authorize the user to get the list the available versions and then copy the appropriate files. By deploying the list of files to be copied to the version folder this would still be supported.
If maintaining this list of files is cumbersome for a large mono-repo, the build system could use pattern matching or other mechanisms for automatically generating it during the build process.