Skip to content

Dependabot Version Updates Support devcontainers

If you use devcontainer.json files to define your development containers, you will now be able to use Dependabot version updates to keep your Features up-to-date. Once configured in dependabot.yml, Dependabot will open pull requests on a specified schedule to update the listed Features to latest. This ensures Features are pinned to the latest major version in the associated devcontainer.json file. If a dev container has a lockfile, that file will also be updated. Dependabot security updates for dev containers are not supported at this time.

CodeQL 2.16.0 is now available to users of GitHub code scanning on, and all new functionality will also be included in GHES 3.13. Users of GHES 3.12 or older can upgrade their CodeQL version.

Important changes in this release include:

In July 2023, we disabled automatic dependency installation for new CodeQL code scanning setups when analyzing Python code. With the release of CodeQL 2.16.0, we have disabled dependency installation for all existing configurations as well. This change should lead to a decrease in analysis time for projects that were installing dependencies during analysis, without any significant impact on results. A fallback environment variable flag is available to ease the transition, but will be removed in CodeQL 2.17.0. No action is required for Default setup users. Advanced setup users that had previously set the setup-python-dependencies option in their CodeQL code scanning workflows are encouraged to remove it, as it no longer has any effect.

We fixed a bug that could cause CodeQL to consume more memory than configured when using the --ram flag. If you have used this flag to manually override the memory allocation limit for CodeQL, you may be able to increase it slightly to more closely match the system’s available memory. No action is required for users of the CodeQL Action (on or in GHES) who are not using this flag, as memory limits are calculated automatically.

We added 2 new C/C++ queries that detect pointer lifetime issues, and identify instances where the return value of scanf is not checked correctly. We added a new Java query that detects uses of weakly random values, which an attacker may be able to predict. Furthermore, we improved the precision and fixed potential false-positives for several other queries.

The measure of scanning Go files in the code scanning UI now includes partially extracted files, as this more accurately reflects the source of extracted information even when parts of a file could not be analyzed. We will gradually roll this change out for all supported languages in the near future.

We fixed a bug that led to errors in build commands for Swift analyses on macOS that included the codesign tool.

For a full list of changes, please refer to the complete changelog for version 2.16.0 and 2.15.5.

See more

Last month, we announced our plan to migrate from a strategy where student repositories are created from a template starter code repository to a strategy where student repositories are forked from the starter code repository.

Today, we are launching these changes as a Public Beta that you can opt-into on a per-classroom basis. You may opt-in your Classrooms by clicking the “Opt-in this classroom” button on the banner displayed at the top of the Dashboard of the Classroom you wish to opt-in.

We anticipate generally rolling out these changes to all Classrooms on June 17, 2024.

This public beta allows us to enable one of our most-requested features from teachers: the ability to change starter code after an assignment has been accepted by students. Students will be able to sync their assignment repository with the upstream starter code, allowing teachers to correct starter code mistakes or add additional content after the assignment has gone live to students.

Because there are important differences between creating a repository from a template and forking a repository, there are important changes in behavior for both new and existing assignments in GitHub Classroom. We recommend reviewing the following new behaviors and making adjustments to your assignments if necessary.

Important Changes for Classrooms in the Public Beta

  • All new accepted assignments will be forks, including existing assignments that were created with a template repository. Existing assignment repositories will not be changed, so they will not be able to sync changes from upstream.
  • Starter code assignments cannot be empty. If you are using a starter code repository without any commits, students will not be able to accept your assignment. GitHub Classroom will enforce this requirement for new assignments, but you will need to manually create an initial commit to existing empty starter code repositories in order for students to accept assignments.
  • Starter code commits will no longer be automatically squashed in student repos. A new fork includes the entire commit history of the parent repository, while a repository created from a template starts with a single commit. This can affect teachers who may have assignment solutions in the commit history of the starter code. We recommend using Git on the command line or GitHub Desktop to squash commits of starter code repositories prior to distributing assignments to students if you previously had solutions filled-in the starter code.
  • In order to enable private assignments, your organization must allow forking private repositories. Forking private repositories is not enabled for organizations by default. See managing the forking policy for your organization for information on how to enable this. During the Public Beta, our team is exploring options for automating this step.
  • Student repository visibility will be inherited from the starter code repository. Forks of public repositories cannot be made private on GitHub. As a result, if you wish to use a public template repository as starter code for an assignment where student repositories should remain private, we recommend creating a new repository from the public template and setting it to private prior to using it as starter code in a GitHub Classroom assignment. During the Public Beta, our team is exploring options to automate this step.
  • Private repositories must be in the same organization as the Classroom in order to be used as starter code. If you wish to use a private repository as starter code for an assignment that is housed under your user account or in another organization, we recommend configuring it to be a template repository and creating a new private repository from the template in the same organization as the Classroom prior to using it as starter code in a GitHub Classroom assignment. During the Public Beta, our team is exploring options to automate this extra step.
See more