The new GitHub Issues – September 29th update

Since our last update, we’ve continued to improve the GitHub Issues beta to expand the capabilities of both project tables and boards. Here are some of the recent ships:

🤖 Workflows

Remove the repetition with new automated workflows that help you keep your project up-to-date.

  • Select the workflows you would like to enable in the new workflow screen.
  • Customize the conditionals and methods to fit your flow.

There’s more to come! Keep an eye out for more workflows and our workflow builder coming soon.

Workflows

🧹 Archive your completed items

Keep the context, but remove the clutter. Now, you can easily archive completed work.

  • Select one or more items – try cmd+a (on MacOS) or ctrl+a (on Windows/Linux) – to select a whole column.
  • Hit e to quickly archive all the selected items, or use the item menu.
  • Easily see which projects an item used to be part of from the issue/pull request page sidebar

Archive

✨ Bug fixes & improvements

  • Share with your community: public projects is rolling out to some beta users; see how they are already using it here.
  • Make quick updates, copy and paste is now enabled between cells in the table layout.
  • Export your table with select all by hitting cmd+a (on MacOS) or ctrl+a (on Windows/Linux) and then copying the selected items.
  • Bug fix so meta+click works on the board without needing a card to already be in focus model.
  • We now automatically add a space when you jump to a search bar with a filter already applied so you can immediately add a new filter.
  • Bug fix for a problem where a negative filter over a hidden field resulted in the field values not being loaded.

See how to use GitHub for project planning on the GitHub Issues page and learn more in the FAQ.

Announcing new settings to help teams manage code review assignments. Also improved pull request filtering that lets you see just the pull requests you have been directly requested to review.

New ways to manage code review assignment

Code review assignment helps distribute a team's pull request review across the team members so reviews aren't the responsibility of just one or two team members. New settings give teams more control over the behavior:

  • Limit assignment to only direct members of the team. Previously, team review requests could be assigned to direct members of the team or members of child teams.

  • Continue with automatic assignment even if one or more members of the team are already requested. Previously, a team member who was already requested would be counted as one of the team's automatic review requests.

  • Keep a team assigned to review even if one or more members is newly assigned. Previously, the team review request was always replaced by one or more individual review requests. This would make it difficult to find pull requests where a specific team was requested.

Code review assignments settings can be managed under Team settings > Code review assignment:

image

Better indication when a review request is assigned to a team member

The timeline and reviewers sidebar on the pull request page now indicate if a review request was automatically assigned to one or more team members (because the team uses code review assignment):

image

review assignment

This avoids some of the mystery that previously existed around automatic code review assignments, including whether a user was directly requested to review or the request was assigned.

Discovering just the pull requests you are requested to review

Regardless of whether your team uses code review assignment, you can now filter pull request searches to only include those you are directly requested to review (Awaiting review from you):

image

Previously, you could filter to see your review requests, but this list would include pull requests you or any team you are a member of was requested on. You can still see this list by filtering on Awaiting review from you or your team.


Learn more about pull requests, code review assignment, and searching pull requests.

See more

macOS Big Sur (11) became generally available on GitHub-hosted runners in August 2021. Over the next 8 weeks, jobs using the macos-latest runner label will migrate from Catalina (10.15) to Big Sur (11). During migration, you can determine if your job has migrated by viewing the Virtual Environment information in the Set up job step of your logs.

Start using GitHub Actions to build and publish apps for the Apple ecosystem by updating your jobs to include runs-on: macos-latest

jobs:
  build:
    runs-on: macos-latest
     steps:
      - uses: actions/checkout@v2
      - name: Build
        run: swift build
      - name: Run tests
        run: swift test

The macOS 11 Big Sur runner image has different tools and tool versions than macOS 10.15 Catalina. See the full list of changed software.

If you spot any issues with your workflows when using Big Sur, please let us know by creating an issue in the virtual-environments repository.

See more