Q3 updates

[HarithaVattikuti]

Q3 Quarter Updates
Post 1

Hi everyone!
Over the last quarter (FY23 Q3), our Infosys teammates have been supporting our setup-actions and have added a number of new features we'd like to showcase!
setup-python
Dependency updates
We updated dependencies like @actions/cache,@actions/http-client and semver in #817 as part of v5.1.0.
Added fallback to "raw" endpoint for manifest when rate limit is reached
We have implemented leveraging the raw API to retrieve the version-manifest, as it does not impose a rate limit and hence facilitates unrestricted consumption without the need for a token for Github Enterprise Servers in #766 and #835 as part of v5.1.0. This is particularly beneficial for GHES runners, which often share the same IP due to Network Address Translation (NAT), to avoid the quick exhaustion of the unauthenticated rate limit.
setup-java
We updated actions/httpclient version to 2.2.1 in #607 and other dependencies @actions/cache,@actions/http-client and semver as part of v4.2.0 and included node-versions packaging of arm64
.tool-versions file support along with .java-version file

The .java-version-file is a configuration file used in some Java projects to specify the version of Java that should be used. This file is particularly useful in projects where the required Java version may differ from the one installed on the developer's machine or the build server. We've extended support to accommodate the .tool-versions file as an input for the .java-version-file.
This enhancement, incorporated in versions v4.2.0 and v4.2.1. It accepts only files named as ‘.tool-versions’. In the .tool-versions file, java version should be preceded by the java keyword, e.g., java 17.0.7. asdf

Included packaging of arm64- setup-node

Added support for packaging of node-versions for arm64 as part of 857. In this feature request we added the packaging support for arm64 architecture to the node-versions along with x64. The action firstly tries to set up Nodejs from the hostedtoolcache directory. If it does not exist there it will try to find it in node-versions for arm64. Currently we are building arm64 packages on node versions to support setup-node.
Added Arm64 support for Windows Arm64 Runners

In the scope of this pull request, we added arm64 architecture for Windows Microsoft Java binaries as part of v4.1.0. In this pull request, we have introduced support for the arm64 architecture of Windows Microsoft Java binaries. This enhancement, part of the v4.1.0 release, broadens the capabilities of our platform by providing users with the ability to set up workflows using a specific version of Java that is compatible with the Windows arm64 architecture. This is a crucial step towards accommodating a more diverse range of system architectures and meeting the evolving needs of our user base.

setup-dotnet
In the scope of this release the version of the Node.js runtime was updated to 20. The majority of dependencies like @actions/cache,@actions/http-client and semver were updated to the latest versions.

setup-node

1. We updated dependencies @actions/cache,@actions/http-client and semver for node20 in #558 and added fix for cache in #917 .
2. Worked on PR related to node-version-file interpreting entire package.json as a version in #856

The new minor release v4.0.2 includes the below features:

Add support for volta.extends

The functionality of the 'node-version' file input has been expanded to include the volta.extends to resolve the corresponding file and look for volta.node or engines.node fields recursively from the package.json file. In this update, we've introduced support for volta.extends in the 'node-version' file input.This new functionality, detailed in issue #921, provides an additional layer of flexibility when specifying node versions, further improving the utility and versatility of our platform.
Introducing support for arm64 windows in setup node action
Added support to download arm64 for Windows (#927). This pull request introduces support for downloading the Windows arm64 version within the scope of our work. With this enhancement, users will now have the ability to set up workflows with a specific version of Node.js that is compatible with Windows arm64 architecture. This is a significant improvement that broadens the versatility of our platform and caters to a wider range of user needs.

And there you have it! Lots of new features to delight our customers!
Post 2

FY24Q3 Security and feature improvements to setup-actions!
Hello to all of our dear team members!
I would like to welcome you to explore various enhancements and additions our team has developed over the past quarter. Please do feel free to investigate but grab a coffee first! 🙂

Security vulnerabilities that are resolved:
Security is of utmost importance in our project. We continually strive to identify and eliminate any potential vulnerabilities to ensure the safety and trustworthiness of our code.
Overly permissive regular expression range — The security vulnerability is related to the xmlbuilder library. The security vulnerability says that xmlbuilder has too big regular expression. The vulnerability says that xmlbuilder has a regular expression that is too big. After investigation, we decided to close this as a false positive because xmlbuilder created a new project xmlbuilder2 and put xmlbuilder into maintenance mode. Other community members asked the project to migrate to xmlbuilder2 but they were not interested in doing it. After discussing it with our security team, we agreed the issue does not affect our actions and marked the vulnerability as won't fix.
Enhance setup-python Action in GitHub Enterprise Server with Raw API Fallback Mechanism

The action relies on accessing a versions-manifest.json file to get the details of Python versions. However, in a GitHub Enterprise Server (GHES) environment, where many runners (machines executing the workflows) might share the same IP address due to Network Address Translation (NAT), this can lead to a quick exhaustion of the unauthenticated rate limit (60 requests per hour per IP address), causing failures in the setup-python action.
The current workaround for this problem is to use a "github.com" token in the setup-python action. This token authenticates the requests to the versions-manifest.json file, thus not counting towards the aforementioned rate limit. However, this solution has one main drawback which is, it doesn't support Pull Requests from forks, because these do not have access to the repository's secrets, including the token.

The added improvement is to use the raw API to retrieve the versions-manifest.json file. The raw API doesn't have a rate limit, so it allows unrestricted access to the file without needing a token. This solution would serve as an automatic workaround for the rate limit issue. If this approach fails, users can still revert to the existing solution of adding a token. This proposal is driven by the frequent encounters with rate limit issues on the GHES and the lack of scalability of the manual token addition method.

Included packaging of arm64

The setup-node action inspects the version-manifest.json for ARM64 packaging for both Linux and Windows within the actions/versions-package-tools repository. This file, version-manifest.json, is often used to enumerate available versions of a version package. For setup-node, it can leverage this file to identify the available Node.js versions for ARM64.
The proposed feature requests that '*-version' tools accommodate this architecture, enabling GitHub Actions workflows to operate on ARM64-based systems. This process would involve identifying the system's architecture at runtime, which could be ARM64 or others like x86_64.
For ARM64 packaging, the setup-node action would confirm that it fetches and installs the ARM64 version of Node.js when operating on an ARM64 architecture. This might include checking the system architecture at runtime and then fetching the suitable Node.js binary based on that architecture.
Depending on the identified architecture, the appropriate version of the language or platform would be downloaded and installed. For the ARM64 architecture, this implies fetching ARM64-compatible binaries. Upon the successful download of the correct binary, it would be unpacked, and the Node.js executable would be incorporated into the system PATH, making it accessible for subsequent stages of the workflow.

Post 3

Hello dear colleagues,
It is a great pleasure of mine to present to you again just a small subset of things our awesome team did in the past few months.
In addition, we fixed several bugs, improved error handling, and updated the documentation, resulting in improved action stability and an increase in average success rate. We encouraged the community, thanked them for the contributions and released new versions with new features and bug fixes on board.

Introducing support for arm64 windows in setup java action
Prior to the implementation of the referenced Pull Request (PR), there was a significant limitation in the system: ARM64 Windows support was absent for all Java distributions. This was a crucial shortcoming as ARM64 architecture is increasingly prevalent, particularly in modern devices running Windows. This lack of support restricted the usability and versatility of Java on these devices.
The PR addressed this gap by introducing ARM64 Windows support for three major Java distributions: Microsoft, Zulu, and Liberica. These distributions are widely recognized and utilized in the Java community due to their comprehensive feature sets and reliable performance. Here's a brief description of each:
Microsoft Java Distribution: Microsoft's own build of the OpenJDK, providing long-term support for specific versions of Java.
Zulu OpenJDK: A free, open-source distribution of the OpenJDK by Azul Systems. It offers a wide range of Java versions and includes support for multiple platforms.
Liberica OpenJDK: BellSoft's Liberica is a certified, Java SE 8, 11, and later, distribution that works on server (Linux x86_64, ARM64, PPC64), desktop (Windows, Linux, macOS), and embedded devices (Linux x86, ARM).
With the PR, ARM64 Windows support is now available for certain Java Development Kit (JDK) versions provided by these distributions. This enhancement broadens the scope of environments where these distributions and their corresponding JDK versions can be efficiently utilized. It's a significant step forward in expanding the reach of Java and enabling developers to build and run Java applications in a wider range of setups.
It's important to note that the added support may not cover all JDK versions. Users are advised to check the specific supported versions for each distribution. Future updates or PRs might be necessary to extend this support to more JDK versions or other distributions.
In conclusion, the PR not only addressed a key limitation but also significantly increased the versatility of Java use on ARM64 Windows devices. It's a testament to the ongoing efforts to improve and adapt Java to modern technological trends and demands.

And now, my favorite part!
I would like to thank my awesome, epic team for making all of this happen! Thank you all:
❤️