Skip to content

Delete stale code scanning configurations to close outdated alerts

Code scanning configurations can now be deleted from the code scanning alert page. This could be used to delete stale configurations causing alerts to remain open, or delete old configurations which are no longer used.

Code scanning can be configured to use different tools, target different languages, or even analyze different parts of the codebase in the same repository. In certain circumstances more than one of these configurations may produce the same alert. However, if one of the configurations is no longer used and becomes 'stale' you may find that the alert is fixed in one configuration but not in the stale configuration, which is potentially confusing. Today we are releasing a new feature that allows you to easily delete stale configurations which cause alerts to remain open after they've been fixed.

In the code scanning alert page, the counter in the 'Affected branches' sidebar shows the number of configurations for the branch. Click a branch to view the configuration details, and delete configurations as required. A configuration is deleted for a branch, so may have an impact on the status of other alerts on the same branch. When a configuration is deleted, a timeline entry is recorded on the alert, and repositories in an organization also record an audit log entry. If a configuration is deleted by mistake, re-run the analysis to update the alert and reinstate the configuration.

Delete code scanning configurations

Read more about removing stale code scanning configurations and alerts.

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.

    Block direct push PR

    Block direct push CI

  • 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.

    Required workflows ref

Link to Documentation

Note: Required workflows is currently in beta.

See more

Today's Changelog brings you auto-add and auto-archive workflows for all users to make managing your project a breeze, and tasklists improvements!

🤖 Automatically add and archive project items

We previously announced the public beta of the auto-archive workflow and the auto-add workflow for Enterprise users, and today we are excited to share these are now available to everyone!

From the Workflows page in your project, configure the filter criteria for when you want to automatically archive items from your project via Auto-archive items, as well as automatically adding items from a repository to your project via Auto-add to project.

Note Multi-repository auto-add workflows are only available to Team and Enterprise users

✅ Tasklist improvements

As part of our ongoing Private Beta for Tasklists, we continue to ship weekly improvements! We're letting in new organizations regularly, sign yours up here.

🟣 See completion pills for issues

Issues in your tasklist now have completion pills which indicate whether or not they have children, making it easier to understand how close your tasklist is to completion.

✏️ Edit issue metadata directly from the tasklist

Quickly make edits to assignees, labels and projects straight from a tasklist.

🐞 Tasklist bug fixes and improvements

  • Fixed a bug where labels and assignee meta-data took a very long time to be reflected on tasklists
  • Better support for issue deletion and transfer of issues within tasklists
  • Fixed a visual bug with tasklist drag-and-drop
  • Fixed a bug where long task titles broke tasklists
  • Fixed a bug where empty tasks broke tasklists

Bug fixes and improvements

  • Fixed misaligned field pills on board items
  • Fixed misaligned board columns when grouped by an iteration field
  • Fixed a bug where closed projects were included in the project count

See how to use GitHub for project planning with GitHub Issues, check out what's on the roadmap, and learn more in the docs.

See more