Explicitly manage secrets, add capability to attach source tarball

[nwiltsie]

Description

Closes #28.

This PR has two intermixed changes that will necessitate a major version bump: attaching a source tarball to the releases and changing how secrets are handled.

The source tarball changes are relatively straightforward - I've added a new attach-tarball boolean argument (defaulting to false) to the finalize workflow. If set, the workflow clones the calling repository to source/<repo-name>. If that path exists then the finalize-release script creates a tarball, attaches it to the new release (which thankfully works even for drafts), and includes a note in the PR comment.

The secrets thing fell out of me trying properly handle the default and PAT tokens in the workflows. Rather than hard-coding our secret name (UCLAHS_CDS_REPO_READ_TOKEN), each workflow now has a token secrets input that needs to be supplied like so:

jobs:
  prepare-release:
    uses: uclahs-cds/tool-create-release/.github/workflows/wf-prepare-release.yaml@v1
    with:
      bump_type: ${{ inputs.bump_type }}
      prerelease: ${{ inputs.prerelease }}
    secrets:
      token: ${{ secrets.YOUR_PAT }}

Doing that will make this useful for organizations other than us, and is the correct way to do it, but it unfortunately does require rewriting a bunch of workflows - hence the need for a major version bump thereafter.

Here are several examples of this working in a testing repository:

• PR with draft release:
  • https://github.com/uclahs-cds/user-nwiltsie-pipeline/pull/46
  • https://github.com/uclahs-cds/user-nwiltsie-pipeline/releases/tag/v2.2.5
• PR with direct release:
  • https://github.com/uclahs-cds/user-nwiltsie-pipeline/pull/45
  • https://github.com/uclahs-cds/user-nwiltsie-pipeline/releases/tag/v2.2.4

Both of those releases have a source_code_with_submodules.tar.gz attachment (generated by the old workflow) and an identical Source code with submodules (tar.gz) (generated by the new workflow).

Checklist

• This PR does NOT contain Protected Health Information (PHI). A repo may need to be deleted if such data is uploaded.
  Disclosing PHI is a major problem¹ - Even a small leak can be costly².

• This PR does NOT contain germline genetic data³, RNA-Seq, DNA methylation, microbiome or other molecular data⁴.

• This PR does NOT contain other non-plain text files, such as: compressed files, images (e.g. .png, .jpeg), .pdf, .RData, .xlsx, .doc, .ppt, or other output 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.

Footnotes

1. UCLA Health reaches $7.5m settlement over 2015 breach of 4.5m patient records ↩

2. The average healthcare data breach costs $2.2 million, despite the majority of breaches releasing fewer than 500 records. ↩

3. Genetic information is considered PHI.
   Forensic assays can identify patients with as few as 21 SNPs ↩

4. RNA-Seq, DNA methylation, microbiome, or other molecular data can be used to predict genotypes (PHI) and reveal a patient's identity. ↩

[yashpatel6]

Generally looks good to me!