To ensure that the Actions runners are truly ephemeral and more secure, we are now limiting execution timeouts on self hosted jobs to 5 days. If a job reaches this limit, the job is terminated and fails to complete.
If you’re using starter workflows to prepare the build and release steps for your Java projects that use Gradle, these projects will now have more comprehensive dependency graph information in GitHub. The Gradle starter workflows have been updated to automatically submit transitive dependencies to GitHub, improving the quality of dependency graph data and Dependabot updates for these apps.
Learn more about the action these starter workflows use by checking out the Build with Gradle action on the GitHub Marketplace. Thank you Gradle for making these updates!
Join the discussion within GitHub Community.
Starting today, in Actions workflows, the pull_request_target trigger is now supported for repository rulesets that require a successful workflow run. This is in addition to pull_request and merge_group, making pull_request_target the third workflow trigger supported by repository rulesets.
Read our recent general availability announcement to learn more about how organizations can set up policies with repository rules that require a successful workflow run before code can be merged into its repositories.
Learn more in our repository rulesets documentation and don’t forget to ask questions or leave feedback in the community discussion.
GitHub environments can be configured with deployment branch policies to allow-list the branches that can deploy to them.
We are now security hardening these branch policies further by blocking runs triggered from forks with branches that match the protected branch name. We are also preventing tags with the same name as a protected branch from deploying to the environments with branch policies around protected branches.
Learn more about configuring environments with deployment protection rules to set up rigorous and streamlined guardrails for your deployments.
For questions, visit the GitHub Actions community.
To see what's next for Actions, visit our public roadmap.
Today, we are announcing public beta of the new experience for deployments across environments.
Developers and DevOps managers can now view and track the full history of deployments in a repository or filter them across environments to:
- view active deployments across various environments and navigate to the deployment URLs or
- understand who and what commits, PRs triggered a deployment in a given environment or
- monitor the deployment status and duration of deployments or
- trace any deployment to its source workflow and view logs to diagnose any issues or review any pending approvals etc.
Learn more about viewing deployments in your repository through our documentation and watching this video.
For questions, visit the GitHub Actions community.
To see what’s next for Actions, visit our public roadmap.
For securely enabling OpenID Connect (OIDC) in your reusable workflows, we are now making the permissions more restrictive.
If you need to fetch an OIDC token generated within a reusable (called) workflow that is outside your enterprise/organization, then the permissions setting for id-token should now be explicitly set to write at the caller workflow level or in the specific job that calls the reusable workflow.
permissions:
id-token: write # This is required for requesting the JWT
This change would ensure that the OIDC token generated in the called workflow is allowed to be consumed in the caller workflows only when intended.
Learn more about permission settings to enable OIDC in your workflows
Today, we are adding a couple of new improvements to required workflows in GitHub Actions.
- Blocking direct push: Direct pushes are now blocked on branches of the repositories where required workflows are enforced. To push to a branch where required workflows are enforced at the organizational level, create a pull request to make the necessary changes. If you want to allow direct pushes for a particular repository, you must remove the repository as a target from respective required workflows.
- Ability to configure required workflows from refs: Required workflows can now be referenced using any branch, tag, or commit SHA from the repository containing the workflow file, during its configuration. This helps you to freeze your required workflow file to a fully validated golden version and gives you the flexibility to move to latest version after testing it thoroughly. The branch, tag, or commit can be specified in the workflow path text field similar to how it is specified for actions within a workflow yaml.
Note: Required workflows is currently in beta.
Previously, GitHub Actions gets a GITHUB_TOKEN with both read/write permissions by default whenever Actions is enabled on a repository.
As a default, this is too permissive, so to improve security we would like to change the default going forward to a read-only token. You can still flip it to read/write if needed.
This change will not impact any existing enterprises, organizations or repositories. Here is how the defaults are set going forward.
- Enterprises: New enterprises will have read-only token.
- Organizations owned by Enterprise: New organizations will inherit the permissions from parent enterprise.
- Organizations not owned by Enterprise: New organizations will have read-only token.
- Repositories owned by organization: New repositories will inherit permissions from parent organization.
- Repositories owned by personal account: New repositories will have read-only token.
Today, we are adding support for configuration variables in GitHub Actions
Previously, you needed to store this configuration data as encrypted secrets in order to reuse values in workflows.
While extremely secure, this method did not allow for easy storage and retrieval of non-sensitive configuration data such as compiler flags, usernames, server names etc.
Configuration variables allows you to store your non sensitive data as plain text variables that can be reused across your workflows in your repository or organization.
You can define variables at Organization, Repository or Environment level based on your requirement.
Configuration variables can be accessed across the workflow using a new vars context.
The following example shows how configuration variables can be used in a workflow.
jobs:
display-variables:
runs-on: ${{ vars.RUNNER }}
steps:
- name: Use variables
run: |
echo "Repository variable : ${{ vars.REPOSITORY_VAR }}"
echo "Organization variable : ${{ vars.ORGANIZATION_VAR }}"Note: Variables feature is in public beta
Today, we are announcing public beta of required workflows in GitHub Actions
Required workflows allow DevOps teams to define and enforce standard CI/CD practices across many source code repositories within an organization without needing to configure each repository individually. Organization admins can configure required workflows to run on all or selected repositories within the organization.
Required workflows will be triggered as required status checks for all the pull requests opened on the default branch, which blocks the ability to merge the pull request until the required workflow succeeds.
Individual development teams at the repository level will be able to see what required workflows have been applied to their repository.
In addition to reducing duplication of CI/CD configuration code, required workflows can also help companies with the following use cases:
- Security: Invoke external vulnerability scoring or dynamic analysis tools.
- Compliance: Ensure that all code meets an enterprise’s quality standards.
- Deployment: Ensure that code is continuously deployed in a standard way.
We are excited to announce that GitHub app in Slack and Microsoft Teams now supports GitHub Actions workflow notifications.
You can now subscribe to your repository and get notified about GitHub Actions workflow run status from your channel or personal app.
/github subscribe owner/repo workflows
- You will get notified when a new workflow run is triggered. And you can track the live status of the jobs.
- You can track the approval notifications as a reply in the thread and you can approve the notifications directly from channel/personal app.
- Once the workflow is completed, you will get a update as a reply in the thread so that you can complete context and history about the workflow run.
- If something fails, you can choose to rerun the workflow in place and you can also enable debug logs if needed.
Workflow notification filters
Getting notified about each and every workflow run can be noisy. So, we are providing you capability to filter the notifications based on your requirement. You can filter your actions workflows notifications based on name, event, actor and/or branch. You can filter the notifications as below.
/github subscribe owner/repo workflows:{name:"your workflow name" event:"workflow event" branch:"branch name" actor:"actor name"}
- name: Name of your workflow
- event: The event on which the workflow is triggered. View the list of all available events.
- actor: The person who triggered or responsible for running of the workflow.
- branch: The branch on which the workflow is running. Only in the cases where pull_request event is included, the branch will be the target branch the pull request is created for.
Note: When you configure workflow notifications without passing any filters, it is configured by default for workflows triggered via pull requests targeting your default branch.
For more information, please visit the GitHub app guidance for Slack and Microsoft Teams.