Assuming that default security and analysis settings have not been changed at the repository, organization, or enterprise level, which scenario would generate a dependency graph for the repository?

The correct answer is C. when a private repository has a new dependency added to its manifest file. For public repositories, the dependency graph is permanently and automatically enabled by GitHub - it cannot be disabled, so it is always present and does not need to be 'generated' as a new event. For private repositories, the dependency graph must be explicitly enabled…

Dependency Management

Question

Options

Awhen a public repository has a new dependency added to its manifest file
Bwhen a private repository is forked to be used as a dependent
Cwhen a private repository has a new dependency added to its manifest file
Dwhen a public repository is forked to be used as a dependent

How the community answered

(26 responses)

A
12% (3)
B
4% (1)
C
81% (21)
D
4% (1)

Explanation

For public repositories, the dependency graph is permanently and automatically enabled by GitHub - it cannot be disabled, so it is always present and does not need to be 'generated' as a new event. For private repositories, the dependency graph must be explicitly enabled. However, when a private repository has a new dependency added to its manifest file (and the dependency graph feature is enabled at the repository, organization, or enterprise level with default settings), GitHub processes the manifest and generates (or updates) the dependency graph. The scenario in C represents the event that actively triggers generation of the graph for a private repository. Forking a repository (B, D) does not generate a dependency graph in the fork's parent; the fork itself would need its own graph.

Topics

#Dependency Graph#GitHub Advanced Security#Private Repositories#Manifest Files

Community Discussion

No community discussion yet for this question.

Full GH-500 Practice