Refactored examples and added github example with README

[savitaashture]

Changes

Refactored examples and added github example along with README

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you
review them:

• Includes tests (if functionality changed/added)
• Includes docs (if user facing)
• Commit messages follow commit message best practices

See the contribution guide for more details.

[dibyom]

I mentioned this in the BitBucket PR but I think its nicer to have each example that uses a secret create and use its own as opposed to sharing a common secret

[dibyom]

shell-script or bash instead of shell script everywhere in this file

[dibyom]

Thanks for adding this! Might be overkill but we could mention that the "string" is the body and the secretKey is from the example secret?

[dibyom]

Again, if we used our own pipeline/taskrun here, it would be easier to track what got created

[dibyom]

As I mentioned in #578 , I'd prefer adding the binding/template/pipeline/secret in this folder in the same file as it makes it much clearer what is going on (just look at this one file vs looking at 6-7 different files). I know this leads to some duplication but for examples I'm ok with having some repetition in order to help with clarity

[dibyom]

Thanks for addressing the comments. Just two things:

1. Could we put the role/binding/serviceaccount file in one file (say, role.yaml)?
2. Can we squash the commits into one?
   Otherwise LGTM!

[savitaashture]

Thanks for addressing the comments. Just two things:

1. Could we put the role/binding/serviceaccount file in one file (say, role.yaml)?
2. Can we squash the commits into one?
   Otherwise LGTM!

Thank you

1. Modified based on the suggestion
2. squashed commits

I have a question here is if we squash commits we actually loose the history of review comments fix 🤔
I know this is small PR but in case of big feature its actually make sense to keep the history of commits so that it will be easy for the reviewers to see actual fix.

[dibyom]

I have a question here is if we squash commits we actually loose the history of review comments fix 🤔
I know this is small PR but in case of big feature its actually make sense to keep the history of commits so that it will be easy for the reviewers to see actual fix.

Yeah, unfortunately GitHub code review does not handle diffs across commits well. And it is indeed helpful during review to see what comments are addressed. However, I think squashing still makes sense. Otherwise, the master branch gets cluttered with a bunch of small commits which makes it hard to rollback/cherry-pick (as well as figure out exactly what happened).

[dibyom]

/approve
/lgtm

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dibyom

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [dibyom]

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