#6614 Add inclusive source scanning

[prestonvasquez]

Resolves #6614

Changes

Add inclusive terminology scan tool woke to the repository, including the woke-action workflow

Suggest using the configuration file here: https://github.com/canonical/Inclusive-naming/raw/main/config.yml. A configuration can be defined locally, if needed.

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

• Has Docs if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps
• Has Tests included if any functionality added or changed
• Follows the commit message standard
• Meets the Tekton contributor standards (including functionality, content, code)
• Has a kind label. You can add one by adding a comment on this PR that contains /kind <type>. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep
• Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of good release notes.
• Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes

NONE

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: prestonvasquez / name: Preston Vasquez (1a38e12)

[tekton-robot]

Hi @prestonvasquez. Thanks for your PR.

I'm waiting for a tektoncd member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[prestonvasquez]

/kind misc

[vdemeester]

/ok-to-test

[vdemeester]

@prestonvasquez the title of the PR shouldn't use TEP-6614 as there is no such TEP (stands for Tekton Enhancement Proposals, and the list is here). It's a bit confusing for maintainers to see that TEP when it refers to an issue 😝

/lgtm

[jerop]

@prestonvasquez thanks for the contribution -- could you please squash the commits into one?

Use one commit per PR unless there is a strong reason not to ~ standards

[prestonvasquez]

@prestonvasquez thanks for the contribution -- could you please squash the commits into one?

Use one commit per PR unless there is a strong reason not to ~ standards

@jerop I can definitely do that. However, GitHub has a "Squash and Merge" feature for pull requests. Is there a reason why we don't just do that?

[vdemeester]

@prestonvasquez thanks for the contribution -- could you please squash the commits into one?
Use one commit per PR unless there is a strong reason not to ~ standards

@jerop I can definitely do that. However, GitHub has a "Squash and Merge" feature for pull requests. Is there a reason why we don't just do that?

Yes, the main reason for it is that is the "content" of the commit it generates. It will generate a commit with each commit message inlined. So if there is a "merge" commit in there, or some wip commit, etc.. the message will have little sense. The idea is more or less to make sure that all commits that get merged are well formatted and make sense (we do miss some from time to time that's sure). The UI of GitHub allows to "customize" the message when merging, but on this project (and in most big OSS project), we are never merging manually PR, it's a bot doing that, and the bot cannot really rephrase the squash commit. So that's why we only use the rebase and merge flow, and we usually require 1 commit per pull-request, except when there is a really strong case for multiple.

[vdemeester]

/approve

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: vdemeester

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [vdemeester]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Yongxuanzhang]

/lgtm

[afrittoli]

The GitHub actions used here are not permitted by the current configuration - I will add them to the configuration now, but I'm concerned that this was merged without the job actually having been tested @vdemeester @Yongxuanzhang

[afrittoli]

I got a successful run on #7356 now, so it's all fine.