Availability of blueprints using the self-service

[netomi]

The self-service now supports the definition of blueprints on GitHub organization level. A blueprint can be seen as a little helper to transform a GitHub organization and its repositories into a desired state, e.g.:

• ensure a security policy is present
• pin all actions used in workflows
• ensure that a .github repository exists
• enable code scanning for all repositories containing java code
• ...

Modus operandi

Once a blueprint is defined for a GitHub organization, its configuration and status can be monitored in the dashboard. On a regular basis, the self-service will check any matching repository if it is already in the desired state. If this is not the case, a PR will be opened to remediate the situation. This PR can then be reviewed by committers of the project and adjusted as needed (if the blueprint supports modifications). Once the PR got merged, the status of the blueprint will be re-evaluated and displayed accordingly in the dashboard.

In case a suggested PR from the blueprint does not match the needs of the project, this blueprint can be dismissed by closing the PR without merging it. The self-service will then not re-check that blueprint for this specific repository unless the PR gets reopened by a committer.

Supported blueprint types

Currently, the following types are supported:

• required_file: requires that a certain file is present in a repository
• pin_workflow: pins any used 3rd party action in workflows

Example blueprints

• Adoptium: require a dependabot_auto_merge.yml workflow
• Eclipse CSI: add a CODE_OF_CONDUCT.md to the .github repo
• Eclipse CSI: pin actions in workflows

Monitoring

Here you can see an example monitoring example for a blueprint defined in in the Eclipse CSI project:

Next steps

Currently we are testing a set of blueprints on a small number of projects / organizations, but plan to define some global blueprints that would apply to all Eclipse projects.