Roadmaps in Projects are now generally available

Today we are announcing the general availability (GA) of roadmaps in GitHub Projects! 🎉

🗺 Roadmaps for all

Since we announced the public beta of roadmaps earlier this year, we've shipped exciting updates that allow you to quickly adjust your roadmaps and visualize and track work with important milestones and dates, alongside lots of bug fixes and improvements. Thank you to everyone who participated in the beta for all of the feedback! 💖

To get started with a roadmap, select the roadmap layout when creating a new project, or create a new roadmap in an existing project by selecting "Roadmap" in the view options menu.

📍 Track important dates with roadmap markers

If you are using milestones to track progress for larger bodies of work, iteration fields to plan out your weeks and months, or date fields for important deadlines, roadmap markers help you and your team keep track of important upcoming dates. Configure these from the Markers menu to make sure all of your important dates are visible on your roadmap.
Roadmap with markers

⚡ Quickly adjust roadmap items

Plans often change, and so can your roadmaps! Quickly make edits to your roadmap items by dragging and dropping them to a different date or iteration, or moving them to another status or team.

✨ Other enhancements

  • Create a roadmap from the Select a template dialog when creating a new project
  • Edit item titles directly from the table
  • Use arrow keys for navigating table items
  • Use the floating + Add items bar when there is no 'Group' field selected
  • Resize the table using keyboard navigation

✍ Tell us what you think!

We want to hear from you! Be sure to drop a note in the discussion and let us know how we can improve. Check out the documentation for more details.

✨ Bug fixes and improvements

  • Enabled vertical scrolling in the Workflows page
  • Fixed a bug where the New column menu was appearing again when adding a new board column
  • Fixed a bug where the Add selected items button was out of view in the bulk-add pane
  • Updated the github-project-automation link in the issue timeline to redirect to Automating your project documentation
  • Moved reactions on issues and pull requests to the bottom left of the comment box, making it easier to respond after reading and creating consistency with discussions
  • (Tasklists Private Beta) "Convert to Issue" is now more discoverable on the tasklist item versus in the three-dot menu
  • (Tasklists Private Beta) Fixed a bug where some repository names were getting cut off

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

Block ambiguous branch and tag names

GitHub blocks branch and tag names which begin with refs/.

Under the hood, all Git refs begin with a prefix (refs/heads/ for branches and refs/tags/ for tags). In typical use, though, users rarely see these prefixes, so they're silently handled by GitHub, the Git client, and other tools. When a similar string is used as the beginning of the visible part of the branch or tag name, this results in ambiguity: did the user intend refs/heads/feature or refs/heads/refs/heads/feature? In nearly all cases, refs/ in front of a branch or tag name is accidental and becomes a problematic surprise later.

This change blocks new introductions of such names. Repositories with existing branches named this way can still push updates to those branches.

See more

Code scanning API to enable default setup with CodeQL on a repository

Code scanning have shipped an API for repositories to programmatically enable code scanning default setup with CodeQL.

The API can be used to:

  • Onboard a repository to default setup: gh api -X PATCH /repos/[org-name]/[repo-name]/code-scanning/default-setup -f state=configured
  • Specify which CodeQL query suite to use in the default setup configuration: gh api -X PATCH /repos/[org-name]/[repo-name]/code-scanning/default-setup -f query_suite=extended
  • View the current default setup configuration for a repository: gh api /repos/[org]/[repo-name]/code-scanning/default-setup
  • Offboard a repository from default setup: gh api -X PATCH /repos/[org-name]/[repo-name]/code-scanning/default-setup -f state=not-configured

When you onboard a repository via the API, you will recieve a workflow run ID which can be used to monitor the setup progress. This can be used to see the status and conclusion of the run: gh api repos/[org-name]/[repo-name]/actions/runs/[run-id] --jq '.status, .conclusion'

{
  "state": "configured",
  "languages": ["javascript", "ruby"],
  "query_suite": "default", 
  "updated_at": "2023-02-24T20:00:42Z"
}

For more information, see "Get the code scanning default setup configuration" and "Update the code scanning default setup configuration".

See more
View all changes