Initial Jammy Tiny Implementation

[fg-j]

Summary

Resolves #1

To Do:

• Create an action that searches previous releases for patched USN JSON files. Pass this JSON as input to the Get USNs action.
• Create an action that takes two package receipts as input and produces a package diff split into lists of added and removed packages as output. May be very similar to this existing action.
• Add a check to see if packages have been REMOVED since the previous release. Fail the release workflow if so.
• Update the create release workflow to only cut a release if
  • the acceptance tests pass AND
  • either of the build/run images are different than the previous release OR
  • the force-creation flag is set
• Fix the Increment Tag action to allow re-tagging a commit that's already been tagged (Allow re-tagging the same commit github-config#474)
• Do not report the build as failed if there are no changes - just do not create a release.
• Actually run the integration tests
• TODOs in stack/stack.toml
• TODOs in metadata_test.go
• TODOs in actions/find-release-asset/entrypoint
• TODOs in actions/find-and-download-asset/action.yml
• TODOs in scripts/receipts.sh
• TODOs in actions/get-usns/entrypoint/main.go
• TODOs in .github/workflows/create-release.yml
• Remove extraneous comments / dead code

---

Outstanding issues that can/should be tackled later

• Evaluate rewriting actions in golang (with tests as appropriate) Refactor stacks actions #4
• Add test coverage to the get-usns action Add test coverage to stacks actions github-config#482
• Refactor the workflows and actions into a common location so we can re-use them in other stacks
• Evaluate how re-usable the notify on failure step is - can we abstract that action and re-use it in other pipelines? Extract Alert on Failure into an Action #5
• Evaluate whether we should validate the uploaded release artifacts after we upload them to the newly-created release Validate release after it is created in stacks create-release workflow github-config#728

Checklist

• I have viewed, signed, and submitted the Contributor License Agreement.
• I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
• I have added an integration test, if necessary.
• I have reviewed the styleguide for guidance on my code quality.
• I'm happy with the commit history on this PR (I have rebased/squashed as needed).

[ryanmoran]

@fg-j & @robdimsdale, the broad strokes on this PR look great! I have some concerns about the size and complexity of the create-release.yml workflow though. I've made some comments in a couple of areas that I hope could reduce some of that complexity. Let me know what you think.

[fg-j]

❗ quick pause!

I'd like to propose we switch to using syft to generate package receipts/SBOMs before this merges!

Very easy to implement. See #8

I've moved this PR into draft state while I finish iterating on the new package receipt approach. I'll undraft once it's completed.

[sophiewigmore]

Tested locally on my Mac workstation and found logging/documentation helpful:

• scripts/create.sh
• scripts/receipts.sh
• scripts/test.sh
  Also found the create-release workflow steps to be pretty clear. I think I would benefit as a maintainer having the different release criteria outlined somewhere (i.e. when an auto-release can happen vs when pressing the big red button is needed), however I don't think that needs to happen here. I left one nitpick change and then I'm personally good to approve this in and see how it goes maintaining it and using the workflows in reality.

[sophiewigmore]

I just merged in paketo-buildpacks/github-config#477 also, if you wish to update the workflow to use the issue-filing action. Up to you though

[fg-j]

@sophiewigmore Let's just get this PR in and we can tidy up the failure alert later.

[sophiewigmore]

@ryanmoran anything else you'd like on this? Otherwise I'm merging it in

[ryanmoran]

@sophiewigmore, nothing that should block this going in. Merge at will.