Script to make PR authors aware if they are modifying templated files

[trexfeathers]

This has a few different permutations, plus I've made some minor changes to the existing notify_updates() script, so I intend to produce some demonstrations of this all working before I take it out of draft.

The demonstrations below use the demo_templating branch. The only differences from prompt-share are those that enable demonstrations (see diff).

notify_updates()

The following issues were generated when the workflow ran against the same code used by this branch:

• The Template for .pre-commit-config.yaml has been updated trexfeathers/iris#91
• The Template for demo_1.py has been updated trexfeathers/cf-units#7

Thus demonstrating that this PR does not break existing functionality

prompt_share()

The new routine

Two demo pull requests

• Pull request to demonstrate templating prompt-share routine trexfeathers/cf-units#8
• Pull request to demonstrate templating prompt-share routine trexfeathers/iris#92

What these demonstrate

• The form of prompts
  • A new issue on the .github repo
  • A new review on the PR
• Prompting the user when they have modified a templated file
• Prompting the user when their file is a likely candidate for templating (based on a hard coded list of parent directories)
• The ability to ignore un-templated files
• Handling multiple files per commit/PR
• That the list of templated files can differ between repos (Iris versus Cf-units)
• Prompts are only created once per file per pull request

Proposal for actions on each repo

See these diffs, which introduce an identical new workflow on cf-units and iris (plus temporarily deleting the other workflows!)

• Cf-units
• Iris

[ESadek-MO]

This is really cool, seems to work really nicely and I haven't spotted anything worrying.

There's a couple of grammar type questions, but otherwise looks GTG.

Am I correct in thinking this will go in first, but won't be functional until actions on other repos are merged in?

[trexfeathers]

Am I correct in thinking this will go in first, but won't be functional until actions on other repos are merged in?

Correct. The good news is that it is not dependent on future hypothetical code. Best way to think of it is 'ready to go', and we have even demonstrated what the future workflows will look like.