Repositories – Enterprise rules and custom properties updates

Custom properties

Screenshot depicting new filter options available

There are new search and filtering options for custom properties now generally available to ensure you can easily find the right property.

  • Managed by allows you to limit your result by the organization or enterprise who manages the property.
  • Property type allows you to limit your result by the available type of properties.
  • Text allows you to limit your result by the context of the property name or values.

Enterprise custom properties

Screenshot of custom property promotion screen

Enterprise custom properties as part of the current preview can now be promoted from an organization to an enterprise property. This ensures properties configured in one organization are available across all organizations in an enterprise.

Enterprise code rulesets

Screenshot of configuring enterprise workflow rule

Required workflows are now available as a new rule in the enterprise code rules preview. This will allow you to target workflows across specific organizations and repositories with a single workflow file managed at the enterprise.

Note: GitHub Enterprise Cloud with data residency support for the enterprise workflow rule will be coming soon.

Join the discussion within GitHub Community.

Recent improvements to Artifact Attestations

We released a collection of improvements to Artifact Attestations to make the verification of attestations easier and more consistent.

Artifact Attestations let you create provenance signatures, which provide an unforgeable paper trail that links your artifact back to its originating workflow run. By verifying the signature, you can gate deployments to ensure that what you deploy is exactly what you built, guaranteeing that the artifact has not been tampered with.

Today we are announcing multiple improvements based on the user feedback we have received:

  • Attestation verification defaults to build provenance: Build provenance is just one type of information that can be attested to an artifact. It provides a verifiable trail that links the artifact back to its originating workflow run, ensuring its authenticity and integrity. However, other types of information can also be attested to an artifact, for example a Software Bill of Materials (SBOM). Attestations can be verified by running gh attestation verify using the GitHub CLI. Previously, verification succeeded as soon as there was any attestation associated with the artifact. However, we observed that provenance is verified in the vast majority of cases. Therefore, we altered the CLI to default to provenance when no predicate type is specified. This change ensures that verification does not pass merely because, for example, an SBOM was attested to the artifact. To verify an SBOM, the predicate type must be explicitly supplied as a parameter using gh attestation verify with the --predicate-type parameter.
  • CLI outputs evaluated policies during verification: When verifying an attestation, the CLI now outputs all the policies it evaluated to determine whether the verification succeeds or fails. This increases transparency, making it easier to understand the reasons behind the verification outcome.
  • Attest actions support multiple subjects: Following the release to support attesting multiple subjects, we have enhanced our attest, attest-build-provenance and attest-sbom actions to also accept a checksum file that contains a list of artifacts and their corresponding digests as input.
  • Attestation verification is now monotonic: This means that once verification passes for an artifact, the addition of another attestation cannot change that status. Verification now succeeds if at least one attestation passes verification. This ensures that downstream processes, such as gated deployments, are not affected for any legitimate build that has a valid provenance attestation, even if someone adds another attestation that is bad or malformed.

For more information about Artifact Attestations, see Using artifact attestations to establish provenance for builds in the GitHub documentation. If you have any feedback on Artifact Attestations, join the discussion in the GitHub Community.

See more

New GPT-4o Copilot code completion model available now in public preview for Copilot in VS Code

Header introducing GPT-4o Copilot model

A new code completion model, GPT-4o Copilot, can now be enabled by VS Code users.

This new model based on GPT-4o mini has additional training on over 275,000 high-quality public repositories in over 30 popular programming languages. As a result, you can expect this model to provide more accurate suggestions and to have better performance.

Getting started with GPT-4o Copilot in VS Code

To get started, open the Copilot menu in the VS Code title bar, select Configure Code Completions... > Change Completions Model.... Alternatively, open the Command Palette and select GitHub Copilot: Change Completions Model....

GPT-4o Copilot access notes

If you are a Copilot Business or Enterprise user, you will first need your administrator to enable this model for your organization by opting in to Editor preview features in the Copilot policy settings on github.com.

If you are a Copilot Free user, using this model will count toward your 2,000 free monthly completions.

The model will also be available soon to Copilot users in all JetBrains IDEs.

Please share your feedback as you try out the new model. It will help us improve the experience for all Copilot users.

See more
View all changes