Add 4-release.yaml to publish container image for the release

[YaSuenag]

Pull Request

#252

Summary

Add 4-release.yaml to ship container image of the release.

This workflow would be triggered when the maintainer creates new release on GitHub release page. The container image has both latest and release version tag. Container image is for both AMD64 and Arm64, and they are pushlished to GitHub Packages.

You can see an example on my forked repo: https://github.com/YaSuenag/carbon-aware-sdk/pkgs/container/carbon-aware-sdk/88739206?tag=v99.0.23

Changes

• .github/workflows/4-release.yaml (new)

Checklist

• Local Tests Passing?
• CICD and Pipeline Tests Passing?
• Added any new Tests?
• Documentation Updates Made?
• Are there any API Changes? If yes, please describe below.
• This is not a breaking change. If it is, please describe it below.

Are there API Changes?

No

Is this a breaking change?

No

[codecov-commenter]

Codecov Report

Merging #342 (314ed12) into dev (273ebb9) will not change coverage.
The diff coverage is n/a.

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

@@           Coverage Diff           @@
##              dev     #342   +/-   ##
=======================================
  Coverage   74.21%   74.21%           
=======================================
  Files          77       77           
  Lines        2637     2637           
  Branches      266      266           
=======================================
  Hits         1957     1957           
  Misses        598      598           
  Partials       82       82           

[danuw]

Hi @YaSuenag , as discussed previously, I really believe this should be triggered by a merge into main, and take its version from a variable?

I suppose I look at it the other way where we would automate creating the release page, when your suggestions imply that creating the release manually is the starting point.
Can we cover that in the call tomorrow morning so we can make a decision and either approve or update accordingly?
This may be due to my inexperience of trying the full process - may be worth us trying both in a forked repo to be able to confirm (we can also plan that after tomorrow's call)

Speak tomorrow

cc @vaughanknight @Willmish

[YaSuenag]

This workflow would be fired when GitHub release would be created. I assume each official release would be appeared in GitHub Release like https://github.com/Green-Software-Foundation/carbon-aware-sdk/releases/tag/v1.0.0 It doesn't matter if it is manual or not.

I think this workflow should depend on release page. So we need to deploy other workflow(s) if we want to create new release automatically when we pushed some commits in main branch.

may be worth us trying both in a forked repo to be able to confirm

Ok, but I tested this PR on my forked repo as I wrote before: https://github.com/YaSuenag/carbon-aware-sdk/pkgs/container/carbon-aware-sdk/88739206?tag=v99.0.23

[danuw]

OK, let's discuss with the group tomorrow morning. Otherwise, happy to go with those changes and update in the future as needed.
@YaSuenag, If you get a chance for tomorrow's meeting (today for you by now), can you provide a quick bullet point list of the steps to release please? (e.g. 1- merge to main? 2- create release page? 3- define release number? 4- add release notes? 5- launch workflow ? 6- package is created?)

[YaSuenag]

I will attend today's call, but I put down release workflow what I think in below:

1. Merge dev to main (manually)
2. Add release tag to main (e.g. v1.1) (manually)
3. Create release page from the tag which is added in 2.
   • We can create the release automatically via GHA which would be kicked when merging into main happens, however we need to create the workflow for it.
4. Publish WebAPI container to GitHub Packages (4-release.yaml)
   • It would be fired automatically when the release page was published.
5. Publish WebAPI client libraries to GitHub Packages
   • Maven (Java), NuGet (.NET), npm (JS)
   • We can run these workflows in parallel, but they should be fired automatically after 4 because they should be generated from OpenAPI document provided by WebAPI container. (We can set workflow dependencies)
   • For some clients (Java, JS at least), client API document should be uploaded to GitHub Pages.
6. Update GitHub Pages if need
   • We can fire it automatically if we create its workflow.

I'm not sure when the release note should be created. Before 1 if it should be included in dev? After 2 if it should be included in main only?

[YaSuenag]

The workflow in above is ok? If so, I think we can merge this PR.

[danuw]

Hi @YaSuenag , let's connect to merge this and check the first release. let me know