Current:

• PR is created
• Maintainer labels PR so it gets categorized for release
• PR is reviewed, approved and merged into base branch
• GitHub Action creates release draft
• Maintainer validates draft and publishes release (and added to discussion Announcements)
• Maintainer locally creates GitHub Action image, tags it (latest, vX, vX.X.X) and pushes it to ghcr.io

Desired:

• PR is created
• GitHub Action to validate label present fails
• Maintainer labels PR so it gets categorized in release
• GitHub Action to validate label present passes
• PR is reviewed, approved and merged into base branch
• Release automatically created (and added to discussion Announcements)
• GitHub Action container image created, tagged (latest, vX, vX.X.X) and pushed to ghcr.io

Is your feature request related to a problem?

No

Related OSPO Tool

automatic-contrib-prs GitHub Action, cleanowners GitHub Action, evergreen GitHub Action, contributors GitHub Action, issues-metrics GitHub Action, stale-repos GitHub Action, internal-contribution-forks GitHub App

Describe the solution you'd like

Add the OSSF Scorecard GitHub Action to all OSPO GitHub Actions and Apps

Why?

Allows us to detect supply chain security for this GitHub Action.

Actions

• setup GitHub Action
• add badge to README once wired-up

Describe alternatives you've considered

Tools available on the Security -> Add Tools page.

Additional context

No response

Link to "almost everything" at https://github.com/github/github-ospo/blob/main/policies/licensing.md is a 404. It points to https://github.com/github/github-ospo/blob/main/policies/XXX.

It appears currently the existing GitHub issue templates of this project are intended for the actual open source projects themselves:

However, if you just want to report something against this project here (github-ospo), these templates are quite irritating. Would it make sense to have an additional issue template to report issues against github-ospo, or remove the existing templates (or move them to a separate folder) if they are not actually applicable directly here?

New Action request

Description

It would be helpful to be able to label contributions to a project that come from outside the owning team. This is beneficial for being able to recognize InnerSource practices and measure statistics related to that. This action could be combined with the issue-metrics action to get those statistics for issues/and PRs labeled as InnerSource. InnerSource in this case would be defined as contributions from a non-owner team within an organization. ie. When a feature team contributes to the observability tools on which they depend but do not own as an area of responsibility.

Additionally it may be helpful to "label" the repository with a Repository Topic so that it can be identified as a repository that practices InnerSource.

One complication that would need to be overcome here is the method by which a contribution is determined to be from a "non-owner" team. The tool could rely on several places to get ownership information:

• Interface with Backstage API assuming that there is a Backstage instance that has a complete catalog of repos with ownership information
• Codeowners file (If someone or a group they belong to is in the codeowners file then they could be considered an owner)
• An org chart interface (API) (such as workday, etc.)
• Other ideas? Open to thoughts here...

This project has currently a stale.yml file, however it appears probot-stale is not actively maintained anymore, see probot/stale#385.

Though in general, all these stale bots can be disruptive for contributors (see for example actions/stale#719 and linked issues and discussions), so maybe unless you really find yourself in a situation where there are too many outdated issues / pull requests in the future, would it make sense to remove the stale bot?

Is your feature request related to a problem?

Yes. Currently we have to make manual PRs to each action when we want changes.

Related OSPO Tool

automatic-contrib-prs GitHub Action, cleanowners GitHub Action, contributors GitHub Action, evergreen GitHub Action, issues-metrics GitHub Action

Describe the solution you'd like

https://docs.github.com/en/actions/creating-actions/creating-a-composite-action

We can centralize multiple composite actions in this repository (or another) and utilize them in the actual GitHub Action repos and allow dependabot to handle update PRs.

List of composites to start (maybe):

• auto-labeller
  • unknown if .github/release-drafter.yml can live in this repo or has to be in each
• pr-title
• release
  • unknown if .github/release-drafter.yml can live in this repo or has to be in each
• super-linter
  • which would include the contents of the linter folder (maybe?)

This will centralize the code so we can make it in one place. Hopefully.

Describe alternatives you've considered

Keep updating each repo manually. 😱

Additional context

No response

Is your feature request related to a problem?

Not really. The OSSF GitHub Action Issue states if we use a ruleset instead of a branch protection we can use the base/given GH_TOKEN instead of a custom PAT that needs additional permissions.

We should also use GitHub's newer tooling on our repositories to be an example of usage.

Related OSPO Tool

• automatic-contrib-prs GitHub Action
• cleanowners GitHub Action
• contributors GitHub Action
• evergreen GitHub Action
• internal-contribution-forks GitHub App
• issues-metrics GitHub Action
• stale-repos GitHub Action

Describe the solution you'd like

Migrate from branch protection rule to ruleset

We will want the permissions to initially match 1 to 1.

Describe alternatives you've considered

N/A

Additional context

N/A

There are 11 references to XXX in https://github.com/github/github-ospo/blob/main/policies/licensing.md. Are those placeholders?

Is your feature request related to a problem?

To ensure that permissions are easier to maintain and keep updated, its a best practice to give permission to a GitHub team and then instead of removing them from a large number of repos, you can just remove them from the team. Well maintained permissions improves security posture.

The task here would be to create a/utilize an existing GitHub action or App to accomplish this.

New Action request

Create an action or app to watch new repo creation in an org and to trigger an issue in that repo asking if it should be marked as InnerSource (via adding a repository topic) and grant permissions to a configurable GitHub team (presumably an all-employees team).

New Action request

I would like to be able to measure DORA metrics on a repo or set of repos. Evaluate existing solution

Checklist

• Update GitHub Actions section of README linking to the new App or Action
• Write a blog post on GitHub Blog about the new App or Action
• Add App or Action to todogroup/awesome-ospo via pull request

In file policies/contributor-license-agreements.md are typos:

"[...] Not all projects will reqiuire a CLA but should a one be required to [...]"

should be

"[...] Not all projects will require a CLA but should one be required to [...]"

Currently the GitHub OSPO GitHub Actions only allow authentication via a personal access token (PAT). Many enterprise customers require GitHub App authentication for their organizations. This is to ensure authentication is not related to a single user.

We should extend each GitHub Action to allow for this.

This introduces 3 new environment variables:

• GITHUB_APP_ID
• GITHUB_APP_INSTALLATION_ID
• GITHUB_APP_PRIVATE_KEY

See documentation for more details.

Repos (PRs):

• stale-repos: github/stale-repos#92
• cleanowners: github/cleanowners#30
• issue-metrics: github/issue-metrics#221
• evergreen: github/evergreen#79
• contributors: github/contributors#80
• automatic-contrib-prs: github/automatic-contrib-prs#43

Currently, the various ospo actions are completely independent. But users who adopt several of them end up restating a lot of configuration for them which would ideally be centralized. As concrete examples, setting:

• a list of repositories to ignore from reporting, or conversely a list of ones to only report
• whether to execute in dry run mode or not
• output formats / destinations that are not the default
• ... probably others ...

would be better served by a common configuration file that all of the actions know to look for.

Is your feature request related to a problem?

Sometimes I just want to run the tool/action without doing any harm. I'd like to be able to run in dry_run mode on any of the actions. I believe cleanowners is the only one that has it.

Related OSPO Tool

automatic-contrib-prs GitHub Action, contributors GitHub Action, internal-contribution-forks GitHub App, evergreen GitHub Action, issues-metrics GitHub Action, stale-repos GitHub Action

Describe the solution you'd like

See dry_run functionality in cleanowners action

Describe alternatives you've considered

No response

Additional context

No response

"issue in this repo" link in https://github.com/github/github-ospo/blob/main/docs/foundations.md points to https://github.com/github/github-ospo/blob/main/docs/XXX and is a 404.

Is your feature request related to a problem?

Pinning using a cryptographic hash or signature is considered a Best Practice to ensure that a specific version of a component is used, which can help in making builds more reproducible and trustworthy. All of our GitHub OSPO Actions do not follow the best practices in terms of being immutable ("pinnable").

Related OSPO Tool

stale-repos GitHub Action, issues-metrics GitHub Action, automatic-contrib-prs GitHub Action, evergreen GitHub Action, cleanowners GitHub Action, contributors GitHub Action

Describe the solution you'd like

See remediation paths at https://github.com/boostsecurityio/poutine/blob/main/docs/content/en/rules/unpinnable_action.md#remediation

Ideally we would make our actions pinnable, update our docs to encourage that practice, and ensure our CI components are all pinned.

Describe alternatives you've considered

none

Additional context

Found based on running the poutine tool

Is your feature request related to a problem?

I'm a fan of having PRs use the DCO GitHub App to enforce the Developer Certificate of Origin aka commit signing on all commits (contribution confirmation and ownership).

The Developer Certificate of Origin (DCO) is a lightweight way for contributors to certify that
they wrote or otherwise have the right to submit the code they are contributing to the 
project.

It's better than CLAs (in my opinion) and easier to ensure.

Related OSPO Tool

automatic-contrib-prs GitHub Action, cleanowners GitHub Action, contributors GitHub Action, evergreen GitHub Action, issues-metrics GitHub Action, stale-repos GitHub Action, internal-contribution-forks GitHub App

Describe the solution you'd like

Add the app to each of the OSPO tools. Before we do that we'd update the pull request template and CONTRIBUTING.md mentioning the change and requirement.

Describe alternatives you've considered

Certificate License Agreement (CLA) is an older way to do the same thing, confirm ownership and who is contributing.

Additional context

Currently we mention Legal Notice in our CONTRIBUTING.md but don't confirm it in any way.

Is your feature request related to a problem?

No visibilty of supply chain security in our GitHub Actions

Related OSPO Tool

automatic-contrib-prs GitHub Action, cleanowners GitHub Action, contributors GitHub Action, evergreen GitHub Action, issues-metrics GitHub Action, stale-repos GitHub Action

Describe the solution you'd like

Summary

Add the OSSF Scorecard GitHub Action so we can have automated supply chain security detection. Allows us to add badge to README to show users we are using open source security tooling.

Corresponding Work

Add Tasks that ladder up to this batch

• github/automatic-contrib-prs#52
  • PR coming soon
• github/cleanowners#49
  • PR coming soon
• github/contributors#88
  • PR coming soon
• github/evergreen#90
  • PR coming soon
• github/issue-metrics#232
  • PR coming soon
• github/stale-repos#115
  • github/stale-repos#130

Dependencies

OSSF Scorecard GitHub Action

Supporting Documentation

OSSF Scorecard GitHub Action

Describe alternatives you've considered

No response

Additional context

No response

Is your feature request related to a problem?

No standards on Issue filing by users

Related OSPO Tool

automatic-contrib-prs GitHub Action, cleanowners GitHub Action, contributors GitHub Action, evergreen GitHub Action, issues-metrics GitHub Action, stale-repos GitHub Action

Describe the solution you'd like

Summary

Add Issue Templates to our OSPO GitHub Actions to allow user feedback and ensure we get all the information we require to successfully complete the issue.

Corresponding Work

Add Tasks that ladder up to this batch

• github/automatic-contrib-prs#51
  • github/automatic-contrib-prs#53
• github/cleanowners#48
  • github/cleanowners#50
• github/contributors#87
  • github/contributors#89
• github/evergreen#89
  • github/evergreen#91
• github/issue-metrics#231
  • github/issue-metrics#233
• github/stale-repos#114
  • github/stale-repos#113

Dependencies

None

Supporting Documentation

GitHub Issue Templates

Describe alternatives you've considered

N/A

Additional context

No response

Currently the various ospo actions are completely separate and there's not much connective "tissue" between them and the broader efforts to help OSPOs on GitHub. As a first step, we should update their READMEs to headline the rest of the tools and the github/github-ospo repo, plus indicate that PRs about the code in a specific action lives in its repo, but questions about overall usage or feature enhancements should go here instead. The actions are in:

• github/automatic-contrib-prs
• github/cleanowners
• github/contributors
• github/evergreen
• github/issue-metrics
• github/stale-repos

Ensure our GitHub Actions have similar repo standards

• Makfile
  • the Makefile should utilize similar config files that the GitHub Action workflows use
• README structure
• similar workflows (GitHub Actions) themselves

Repos (PRs):

• stale-repos: github/stale-repos#108
• cleanowners: github/cleanowners#41
• issue-metrics: github/issue-metrics#221
• evergreen: github/evergreen#79
• contributors: github/contributors#80
• automatic-contrib-prs: github/automatic-contrib-prs#43

Is your feature request related to a problem?

From a GitHub Enterprise customer:

We are trying to do some searches and wondering if you have code that would search our repos for repos without any files or that only have a README.md file.

This action would be in the same category as the github/stale-repos action where the goal is to keep an organization well maintained by identifying repositories that potentially shouldn't be there/aren't useful.

Is your feature request related to a problem?

Currently we use a make lint target to run linting locally in each of our OSPO GitHub Actions (example). This "works" but does not cover the larger list of linters that super-linter runs against our code in our linting workflow on each OSPO GitHub Action (example).

The issue is that super-linter does not work well on arm64 architecture (Apple M1, for example). There is an open PR trying to work through this.

Related OSPO Tool

automatic-contrib-prs GitHub Action, cleanowners GitHub Action, contributors GitHub Action, evergreen GitHub Action, issues-metrics GitHub Action, stale-repos GitHub Action

Describe the solution you'd like

We spin up a super-linter container and run linting against the local code

Describe alternatives you've considered

Current: Makefile calling individual tools to try to match the large lister of linters built into super-linter and run in our linting workflow on each OSPO GitHub Action

Additional context

We have people subscribed to the super-linter PR and will try this out as soon as that is merged.

Is your feature request related to a problem?

Several of our actions run into the problem of working through the first X number of repos in an organization when they fail due to rate limiting or max action run times. If they could save state or remember what repos have been evaluated recently, that would be helpful for delivering more value for each action. This happens especially for OSPOs that are working on the "get clean" phase of any task rather than the "stay clean". ie. Every repo in an org of 10k repos needs a dependabot PR opened. (evergreen)

Related OSPO Tool

automatic-contrib-prs GitHub Action, cleanowners GitHub Action, evergreen GitHub Action, issues-metrics GitHub Action, stale-repos GitHub Action

Describe the solution you'd like

Ideas:

• A dump/file saved of repos processed and then an upload for the next run.
• Separate out the scan all repos/get repo list from the action that should be taken into separate actions
• database something something hand wave

Describe alternatives you've considered

No response

Additional context

No response

"you must register your contribution" at https://github.com/github/github-ospo/blob/main/policies/small-code-exception.md points to https://github.com/github/github-ospo/blob/main/policies/XXX. This is a 404.

With the new JWT-protected images on githubusercontent, it's easy to host an image by creating an issue in the same repo and dropping it in there to get a persistent URL.

Is your feature request related to a problem?

Yes, Currently our automated release process on actions releases after every merge to main. This could create more noise than necessary. For example if its only a documentation related update or dependabot PR than we don't really need to create a release for that.

Related OSPO Tool

automatic-contrib-prs GitHub Action, cleanowners GitHub Action, contributors GitHub Action, evergreen GitHub Action, internal-contribution-forks GitHub App, issues-metrics GitHub Action, stale-repos GitHub Action

Describe the solution you'd like

We should only create a release for major, minor, and vulnerability fixes.

Describe alternatives you've considered

No response

Additional context

No response

The page about Contributor License Agreement (CLA) (contributor-license-agreements.md) currently says:

Not all projects will require a CLA but should one be required to contribute to a project ...

Maybe in this context it would be useful to refer to GitHub's Terms of Service which say:

Whenever you add Content to a repository containing notice of a license, you license that Content under the same terms, and you agree that you have the right to license that Content under those terms. If you have a separate agreement to license that Content under different terms, such as a contributor license agreement, that agreement will supersede.

Isn't this just how it works already? Yep. This is widely accepted as the norm in the open-source community; it's commonly referred to by the shorthand "inbound=outbound". We're just making it explicit.

(note sure though how many users are actually aware of this)

Arguably CLAs are a somewhat controversial topic though. Using your favorite search engine to search for advantages and disadvantages should bring up multiple articles and blog posts.
Maybe it would be useful if this repository could provide more information on the topic of CLAs if that is possible, or link to third party sites where advantages and disadvantages are compared (if there is a comprehensive and up-to-date site).

Guide on writing effective alt text

• Add alt text to images in markdown files
• Remove the markdownlint exception for alt images in the file .markdownlint-cli2.jsonc

New Action request

Sometimes an issue or a pull request can't be dealt with properly until some time in the future and it would be nice to be able to configure getting a reminder notification/email. The idea would be to create an app or action that you can write a comment on an issue or PR to remind you to look at it on a future date. ie. /remind-me 2024-01-01

Currently the ospo-actions each make human readable reports, but it'd be beneficial to enable structured output like JSON which could get POSTed to a url. Users who are using an external system for logging or auditing could then parse the result and make use of the data for alerts, visualizations, etc.