Standardize repository layout, update YAML parsing

[nwiltsie]

Background

I have a number of large changes in the works for this repository, but several existing workflows that call this action refer specifically to uclahs-cds/tool-Docker-action/build-release@main. In order to not break existing workflows while making breaking changes, I've created the new branch refactor-base (currently pointing to main) and am going to target all PRs toward it.

Once I'm done with the breaking changes (several PRs from now), I intend to:

1. Tag refactor-base (still not merged into main) as v2
2. Update all calling workflows to use uclahs-cds/tool-Docker-action@v2
3. Merge refactor-base into main

That should keep things stable, reduce the number of tedious PRs to be made in other repositories, and increase the maintainability of this repository.

Description of this PR

This PR accomplishes a few tasks simultaneously:

1. Fixes YAML reader update #10 by replacing https://github.com/marketplace/actions/read-yaml with https://github.com/marketplace/actions/yq-portable-yaml-processor
   • This is a breaking change, as the input denoting the key path has a different format
2. Unpacks the build-release folder, putting the action.yml file in the standard location at the repository's root
   • This is a breaking change.
3. Makes the docker-token input optional, defaulting to ${docker.token}

I tested these changes with a dummy repository containing a basic Dockerfile - https://github.com/uclahs-cds/docker-internal-tests/actions/runs/9473134167/job/26100013560. This line shows that the workflow ran on commit 5290dd2.

Closes #10

Checklist

• This PR does NOT contain PHI or germline genetic data. A repo may need to be deleted if such data is uploaded. Disclosing PHI is a major problem.
• This PR does NOT contain molecular files, compressed files, output files such as images (e.g. .png, .jpeg), .pdf, .RData, .xlsx, .doc, .ppt, or other non-plain-text files. To automatically exclude such files using a .gitignore file, see here for example.
• I have read the code review guidelines and the code review best practice on GitHub check-list.
• I have set up or verified the main branch protection rule following the github standards before opening this pull request.
• The name of the branch is meaningful and well formatted following the standards, using [AD_username (or 5 letters of AD if AD is too long)]-[brief_description_of_branch].
• I have added the major changes included in this pull request to the CHANGELOG.md under the next release version or unreleased, and updated the date.

[yashpatel6]

Looks good!