Skip to content

GitHub Actions – New dashboard view for deployments across environments (public beta)

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.

New Deployment views

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.

Starting today, publishing with provenance is restricted to public source repositories only. Private source repositories are no longer supported for use with provenance for public packages.

As announced on July 11, 2023: npm will verify the linked source commit and repository when users view a package's provenance information on If the linked source commit or repository cannot be found, an error will be displayed. This can occur if a repository is deleted or if it is made private.

Read more about viewing npm provenance and publishing with provenance.

See more

GitHub Codespaces has introduced new access and ownership settings, providing organizations more granular control over which members and outside collaborators are able to create codespaces on organization-owned private and internal repositories.

Screenshot of an organization's Codespaces settings page. Sections titled “Codespaces access” and “Codespaces ownership” contain radio buttons for various options.

Owners of organizations on the Team or Enterprise plan can now select which of their organization's members or collaborators are allowed to use GitHub Codespaces on organization-owned private and internal repositories. In order to use GitHub Codespaces, an organization member or collaborator will need explicit access to GitHub Codespaces and either write or fork permissions on the repository.

Any members or collaborators not explicitly granted access will not be allowed to use GitHub Codespaces within the organization's private or internal repositories. Those members or collaborators may still use codespaces on public repositories owned by the organization, like any other GitHub user.

Screenshot of the Codespace ownership settings section, with radio buttons labeled “Organization ownership” and “User ownership.”

Additionally, organization administrators can select whether member or collaborator codespaces fall under organization or user ownership. Codespaces ownership dictates who pays for a codespace, which policies are applied, and where audit logs from codespace usage are sent. For organization owned codespaces, the organization pays for the codespace, organization policies apply, and the logs are sent to the organization. For an organization to own any codespaces, the organization administrator will need to set a spending limit in order to enable GitHub Codespaces within their organization. Enterprise Managed Users are not able to create user owned codespaces because their usage must be paid for by the enterprise.

Additional Resources

See more