💡 See https://github.com/actions/toolkit/pull/1064 for a better diff!
https://github.com/actions/toolkit contains a variety of packages used for building actions. https://github.com/actions/http-client is one such package, but lives outside of the toolkit. Moving it inside of the toolkit will improve discoverability and reduce the number of repos we have to keep track of for maintenance tasks (such as github/c2c-actions-service#2937).
I checked with @bryanmacfarlane on the historical decision here. Apparently it was just inertia from before we released the toolkit as multiple packages.
The benefits here are:
- Have one fewer repo to keep track of
- Signal that this is an HTTP client meant for building actions, not for general use.
## Notes
- `@actions/http-client` will continue to be released as its own package.
- Bumping the package version to **2.0.0**. Since we're compiling in strict mode now, there are some breaking changes to the exported types. This is an improvement because the null-unsafe version of`http-client` is currently breaking the safety of null-safe consumers.
- I'm not updating the other packages to use the new version in this PR. I plan to do that in a follow-up. We'll hold off on publishing `http-client` v2 to NPM until that's done just in case other changes shake out of it.
Seems that folk are having issues with uploading 0-byte files from
Windows agents. This effectively removes the support for Windows for
uploading from named files that, due to `isFIFO` returning `false` on
Windows for named pipes created using MSYS2's `mkfifo` command, resorted
to checking if the file size is 0 - a common trait of named pipes.
See https://github.com/actions/upload-artifact/issues/281
* Create process to release packages via actions
Co-authored-by: Thomas Boop <52323235+thboop@users.noreply.github.com>
Co-authored-by: Konrad Pabjan <konradpabjan@github.com>
From February 2021, in order to provide feedback on pull requests, Code Scanning workflows must be configured with both `push` and `pull_request` triggers. This is because Code Scanning compares the results from a pull request against the results for the base branch to tell you only what has changed between the two.
Early in the beta period we supported displaying results on pull requests for workflows with only `push` triggers, but have discontinued support as this proved to be less robust.
See https://docs.github.com/en/free-pro-team@latest/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-code-scanning#scanning-pull-requests for more information on how best to configure your Code Scanning workflows.
* Adds option to download using AzCopy
* Bump version number and add release notes
* Ensure we use at least v10
* Negate env var so it disables AzCopy
* Use Azure storage SDK to download cache
* Use same level of parallelism as AzCopy
* Fix naming of variable
* React to feedback
* Bump Node types to Node 12
* Make linter happy
* Pass options into restoreCache method
* Fix tests
* Restructure files and add tests
* Add method to get the default download and upload options
* Include breaking changes in RELEASES.md
Co-authored-by: Josh Gross <joshmgross@github.com>
setup-node currently outputs:
##[warning]Input 'version' has been deprecated with message: The version property will not be supported after October 1, 2019. Use node-version instead
Brian Cristante