Merge remote-tracking branch 'origin/master' into kotewar/allow-http-client-for-cache-download

* Add documentation for notice

This is described in documentation elsewhere.

* Update docs/commands.md

Co-authored-by: Konrad Pabjan <konradpabjan@github.com>

Co-authored-by: Konrad Pabjan <konradpabjan@github.com>

docs/action-versioning.md

@@ -17,7 +17,7 @@ Binding to a major version is the latest of that major version ( e.g. `v1` == "1
 
 Major versions should guarantee compatibility.  A major version can add net new capabilities but should not break existing input compatibility or break existing workflows. 
 
-Major version binding allows you to take advantage of bug fixes and critical functionality and security fixes.  The `main` branch has the latest code and is unstable to bind to since changes get committed to main and released to the market place by creating a tag.  In addition, a new major version carrying breaking changes will get implemented in main after branching off the previous major version.
+Major version binding allows you to take advantage of bug fixes and critical functionality and security fixes.  The `main` branch has the latest code and is unstable to bind to since changes get committed to `main` and released to the market place by creating a tag.  In addition, a new major version carrying breaking changes will get implemented in `main` after branching off the previous major version.
 
 > Warning: do not reference `main` since that is the latest code and can be carrying breaking changes of the next major version.
 

docs/commands.md

@@ -100,9 +100,12 @@ There are several commands to emit different levels of log output:
 | log level | example usage |
 |---|---|
 | [debug](action-debugging.md)  | `echo "::debug::My debug message"` |
+| notice | `echo "::notice::My notice message"` |
 | warning | `echo "::warning::My warning message"` |
 | error | `echo "::error::My error message"` |
 
+Additional syntax options are described at [the workflow command documentation](https://docs.github.com/en/actions/reference/workflow-commands-for-github-actions#setting-a-debug-message).
+
 ### Command Echoing
 
 By default, the echoing of commands to stdout only occurs if [Step Debugging is enabled](./action-debugging.md#How-to-Access-Step-Debug-Logs)

packages/cache/README.md

@@ -47,3 +47,5 @@ const cacheKey = await cache.restoreCache(paths, key, restoreKeys)
 A cache gets downloaded in multiple segments of fixed sizes (`1GB` for a `32-bit` runner and `2GB` for a `64-bit` runner). Sometimes, a segment download gets stuck which causes the workflow job to be stuck forever and fail. Version `v3.0.4` of cache package introduces a segment download timeout. The segment download timeout will allow the segment download to get aborted and hence allow the job to proceed with a cache miss.
 
 Default value of this timeout is 60 minutes and can be customized by specifying an [environment variable](https://docs.github.com/en/actions/learn-github-actions/environment-variables) named `SEGMENT_DOWNLOAD_TIMEOUT_MINS` with timeout value in minutes.
+
+We are also introducing a new variable `DOWNLOAD_WITH_HTTP_CLIENT`, which if set to `true` downloads the cache using plain http-client and not Azure SDK. This has been introduced keeping in mind the problem Azure SDK is causing in downloads getting stuck infinitely.

packages/cache/src/internal/cacheHttpClient.ts

@@ -132,7 +132,7 @@ export async function downloadCache(
 
   if (
     downloadOptions.useAzureSdk &&
-    archiveUrl.hostname.endsWith('.blob.core.windows.net')
+    archiveUrl.hostname.endsWith('.blob.core.windows.net') && !process.env['DOWNLOAD_WITH_HTTP_CLIENT']
   ) {
     // Use Azure storage SDK to download caches hosted on Azure to improve speed and reliability.
     await downloadCacheStorageSDK(archiveLocation, archivePath, downloadOptions)