Hello December! Actions & Packages check-in 📰

[Akash1134]

Hello 👋 Y’all, It’s December!

A new month, a new beginning, and a new focus. This week, I bring you some thrilling new updates, product releases, and love from all corners of the Actions and Packages community. Let’s dive into this!

GitHub Actions Importer - CI/CD migration made easy 🆕

We’ve launched a public preview of GitHub Actions Importer, which helps you forecast, plan, and automate migrations from your current CI/CD tool to GitHub Actions. GitHub Actions Importer gets you up and running faster by planning and executing migrations from your former CI/CD tool to GitHub Actions.

Sign up here to request access to the public preview. Once added, you will receive an email with instructions to get started.

To learn more, see Automating Migrations with GitHub Actions Importer and the announcement on the GitHub blog.

Revolutionize Internet of Things (IoT) software development

GitHub has partnered with Arm to revolutionize IoT software development by making the Arm Development tools (Arm cross-compiler and Arm Virtual Hardware) natively available inside GitHub Actions cloud hosted runners to create an efficient CI workflow. This in-depth article has all of the steps you need to run Arm Virtual Hardware inside GitHub Actions.

From the Release Radar 🚨

Require approval for running workflows from private forks. ✔️

You can now require approval from a user with write permissions to the repository before a workflow run can be triggered from a private fork. To know more about this ship 🚢, see: Enabling workflows for forks of private repositories

Ubuntu-latest workflows will use Ubuntu-22.04 💻

Ubuntu 22.04 became generally available on GitHub-hosted runners in August 2022. Now Ubuntu-22.04 is ready to be the default version for the ubuntu-latest label in GitHub Actions workflows.

Webhook enhancements for environment protection rules ♻️

The workflow_job webhook will now support a new waiting state whenever a job is waiting on an environment protection rule, aligning with the waiting state of the corresponding check run.

Restrict workflows to specific runners using runner group names 🔒

You can now deterministically restrict workflows to run on a specific set of runners using the names of their runner groups in the runs-on key of their workflow YAML. This prevents the unintended case where your job runs on a runner outside your intended group because the unintended runner shared the same labels as the runners in your intended runner group.

From the Community ❤️

Let’s give a round of applause 👏 to these community members for their contributions.

• A brilliant self-solve 💡 by hiddewie Thanks for coming back with the solution ✅ that worked for you and sharing the update.
• Another self-solve by riccardoporreca where he troubleshot a permission issue with ease.
• Laughedelic showcased the power 💪 of Docs, and helped ldeluigi by answering his question.
• Shoutout 🎉 to david-engelmann for doing a great job solving this question about Docker containers.

Want to flex some solving muscled? Help us with these unanswered threads from the month of November 🤝

• Delete branch cache on branch deletion
• Making all CI checks required
• How to create multiple groups with workflows inside it
• Authorized user cannot push in GitHub Action

That's all for now folks. Got feedback or feature requests for anything Actions and Packages? ❓Post them on community and share enhancements you’d like to see on these products. Happy December! Till next time! 🚀