close
The Wayback Machine - https://web.archive.org/web/20250219191221/https://github.blog/changelog/2025-02-19-new-gpt-4o-copilot-code-completion-model-now-available-for-copilot-in-jetbrains-ides/

New GPT-4o Copilot code completion model now available for Copilot in JetBrains IDEs

The new code completion model announced yesterday is available today to all JetBrains users of GitHub Copilot.

To get started, ensure that you are on the latest stable release of the extension (v1.5.35 or above). Click the Copilot icon in the JetBrains IDE of your choice and select Edit model for Completion. This will open the GitHub Copilot settings, where you can switch between models.

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.

See more

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
View all changes