Enable Dependabot version updates from the repository settings page

Dependabot version updates help you keep your dependencies up-to-date by opening pull requests automatically when new versions are available.

With this release, you can now more easily enable and configure Dependabot version updates from your repository’s settings page. Within the "Dependabot" section of the "Code security and analysis" tab, you can choose to enable Dependabot version updates, which will prompt you to create a dependabot.yml config file. If a dependabot.yml file exists, you can access that from the repository settings page.

Note: you still need to configure Dependabot version updates with a dependabot.yml file to enable it.

For more information, learn more about Dependabot version updates and how to configure a dependabot.yml file.

The new GitHub Issues – June 2nd update

Today's Changelog brings you the release of project webhooks, a first exploration into templates and a host of improvements to GitHub Issues.

☁️🪝 Automate more with project webhooks

The first release of webhooks for projects (beta) is now available for Organizations and GitHub Apps. 🤩

Once configured and enabled, webhooks will transmit events for any action taken on project items within your organization. This includes changes made (via projects) to status, assignee, labels, and even draft issue titles and descriptions!

You can find webhooks for projects (beta) in the "Webhooks" section of your organization settings page under the title Projects v2 Items. For more information, including technical specifications, check out the docs.

🦻 We're still developing webhooks, and we'd love to hear your feedback; drop us a line in our Feedback Discussion.

🎨 Get started with templates

When you create a new project, you now have the option of multiple templates to choose from. Start with either the default table or board, or explore one we've created for you with our team backlog or feature templates.

Stay tuned for more with templates in the future. 💖

Select a starting template

🧭 Improved navigation via project header

Quickly understand which organization or user a project belongs to and easily navigate via the breadcrumbs in the project header. We've got more to do here, so please let us know what you think.
Projects Compact Header

✨ Bug fixes & improvements

Other changes include:

  • Bug fix so projects (beta) insights retain URL parameters when switching to custom date ranges.
  • REST API, GraphQL API and webhook support for closed issue reasons.
  • The emoji menu on milestone creation now loads in the correct place.
  • Users trying to upload large files now receive the correct 'file too large' error, not a 'file type not supported' error.
  • Bug fix when converting a task list item to an issue, the ` character is now correctly formatted.
  • When transferring an issue between repositories, if no search results are found there is new UI to help you understand why some repositories are excluded.
  • Using the assignee filter menu on the issues index page, you now have the option to filter by the current user instantly, without having to wait for all possible assignees to load.

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

Users can view and comment on code scanning alerts on the Conversation tab in a pull request

Code scanning flags up potential security vulnerabilities in pull requests — well before code is merged and deployed. Starting today, such alerts will be more visible: they will appear as a review on the pull request Conversation tab. As with any review, developers can then have a conversation about specific areas of the code that was changed.

And of course, from the code review by the GitHub code scanning bot, you can dive deeper into the alert: view the details, check the data flow paths, and dismiss an alert.

Code scanning alert

Code scanning and branch protection rules

Users were already able to configure code scanning as a required check in the branch protection settings in a repository.

With the new code scanning functionality, developers can start a conversation about code scanning alerts. Branch protection rules that require all conversations to be resolved before a PR can be merged apply equally to conversations about code scanning alerts: as soon as a code reviewer comments on a code scanning alert, the PR can not be merged until the conversation is marked as resolved. This helps ensure comments made on alerts are addressed prior to merging.

As you'd expect, when an alert is fixed, the conversation around the alert gets resolved and the PR can be merged.

PR merge blocked because of unresolved conversation

Learn more about GitHub Advanced Security and code scanning.

See more
View all changes