#3187

Preserve assertion-free tests in the JUnit report

OpenBoulea7wants to merge intofrom

Description

Executed tests without reportable assertions or output can disappear from the JUnit report. Emit one root testcase when no section was reported, preserving failures, allowed failures, and skips. This includes generated tests whose final iteration is empty.

For failed cases, reuse the first retained assertion diagnostic so uncaught exceptions keep their error classification and message.

The existing suite totals are preserved, including the assertion-based tests count; an assertion-free suite can therefore still report tests="0".

Validation:

  • Added approval regressions for allowed failures, exceptions, and nested failures before an empty generator iteration, and checked them against unfixed and fixed binaries.
  • The Debug basic-tests CTest suite passes (82/82), including all 29 approval baselines and JUnit namespace normalization.

The platform/compiler/configuration matrix was not run locally for this update.

OpenAI Codex assisted with implementation and test preparation.

GitHub Issues

Closes #2856

Activity

8
codecov[bot]2mo ago

Codecov Report

:x: Patch coverage is 86.95652% with 6 lines in your changes missing coverage. Please review. :white_check_mark: Project coverage is 91.16%. Comparing base (0809213) to head (0041be7).

Additional details and impacted files
@@            Coverage Diff             @@
##            devel    #3187      +/-   ##
==========================================
- Coverage   91.18%   91.16%   -0.02%     
==========================================
  Files         205      205              
  Lines        9101     9142      +41     
==========================================
+ Hits         8298     8334      +36     
- Misses        803      808       +5     
:rocket: New features to boost your workflow:
  • :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
tteo384722mo ago

Enterprise accounts

Get started with top-down administration by understanding the key components of an enterprise account.

An enterprise account is the central point of administration for your business on GitHub. It brings together administrative tools for access management, policies, billing, and more. Enterprise administrators can set up features and policies efficiently at scale before deploying them across the business.

This guide provides an overview of the major administrative features included in an enterprise account. By understanding the tools at your disposal, you will be able to adapt GitHub to your unique needs, set your business up for future scaling, and enable teams to focus on strategic work.

Users

Your enterprise contains all the users who need to access any part of your company's resources on GitHub. Users can be grouped into teams and given access to organizations.

Depending on your enterprise type, you will invite users into your enterprise with their existing GitHub account, or provision dedicated accounts from a central identity provider.

By default, most users have a non-administrative role in your enterprise, which means they have little reason to interact with the enterprise account itself. However, you can change this by granting enterprise roles that provide access to specific settings.

Organizations

An enterprise account may contain one or more organizations. Like an enterprise account, an organization account contains its own administrative features such as audit logs, policies, and teams.

An organization also contains the places where non-admins typically do their work, such as repositories, discussions, and projects. The users in an organization are the people who need to access these places to do their jobs.

Generally, you can govern organizations consistently from your enterprise account. To allow for more tailored and granular administration, you can also delegate some decisions, such as policy settings, to organization administrators.

Teams

Teams are groups of users that you can use to manage people's access to organizations, roles, and licenses at scale. You can use teams to add people to shared projects or delegate duties to specialized teams.

You can define teams at the enterprise level, then grant them administrative roles or add them to organizations, where they can receive organization-level roles and repository access.

Teams can be synced with IdP groups, allowing you to manage any privileges that come with team membership directly from your company's centralized identity management system.

Repositories

Repositories host files such as your company's source code or internal documentation. They are where developers typically do their work, and they contain their own features and administration options that need to live closer to the code, such as GitHub Actions workflows.

Repositories are owned by organizations and are not directly accessible under the enterprise account. However, your enterprise can define custom properties to apply the same governance model to all repositories with shared characteristics. For example, if you do not want anyone to delete repositories that contain production code, this is something you can govern from the enterprise level.

Cost centers

Cost centers allow you to allocate spending on GitHub features to specific business units. They let you define your billing structure independently from other parts of the enterprise, so you can focus on using organization accounts to group related work or governance requirements.

If your account is billed through Azure, cost centers also allow you to bill usage to multiple different Azure subscriptions.

Policies

Enterprise administrators can set policies to govern how people work across your enterprise, such as:

  • IP allow lists to enforce restrictions on where people can access your enterprise
  • Copilot policies to govern which features and models people can use
  • Repository policies to control who can do things like delete, rename, or transfer repositories
  • Rulesets to define how people can interact with important branches, such as requiring pull requests with reviews

Apps

GitHub Apps are a secure way to manage automations across your enterprise. A GitHub App is a dedicated identity that provides scoped tokens to your external scripts and workflows, allowing you to automate processes and integrate with other platforms.

In your enterprise account, you can define app registrations to automate a process consistently across organizations. You can also install apps for automations that take actions on the enterprise account itself, such as creating organizations.

Users can also authorize GitHub Apps to use their GitHub account and data in other applications—for example, to use their GitHub account to sign in to an IDE or connect a CI provider to your repositories.

Next steps

Learn how to set up these features with our Enterprise onboarding journey for GitHub Enterprise Cloud.

copilot-pull-request-reviewer[bot]reviewed1mo ago
copilot-pull-request-reviewer[bot]1mo ago

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.