Demonstrate developer experience of git commit --> deployed Service

[jchesterpivotal]

As an app developer
I want a safe, automated path to production
So that I may help develop better products, faster

When I push to my git repo
And I run kubectl get services (knative Services, not k8s)
Then I see my Service running

When I look at Concourse's UI
Then I see my code was "built"
And I see my code was pushed to GCR
And I see a Configuration was updated
And I see the updated Configuration was applied

---

Note:

The intent of this story is to demonstrate developer experience, rather than particular implementation points. This means it not necessary to use the POC controller. It is acceptable to use fly and a normal Concourse to prove out the experience.

---

I'm working out of this repository

[jchesterpivotal]

What I think needs to happen:

• Setup Knative again
• Setup Concourse again in a way that avoids Istio sidecar injection
• Put together pipeline that goes from commit to deployment

Open question: what repo am I talking about? I figure I could do this with a sample app (or maybe a bunch of them, just to be showy).

[jchesterpivotal]

I decided to start with the sample apps in docs/serving/samples. Not sure which app yet. For deploying I will first use a YAML-writing task and kubernetes-resource. Then consider whether to write a knative-resource to smooth it out more.

[evankanderson]

See #226 and #245 for a couple PRs which might make your life easier. :-)

[jchesterpivotal]

Not yet unfortunately (here I'm working on a demo outside of Build), but definite immediate value.

[jchesterpivotal]

EOD notes:

• Had a basic Concourse pipeline setup pretty quickly.
• Needs some nips and tucks to make it more configurable for other folks to kick the tires.
• I want to explore updating, including how configuration history (git SHA, docker digest) is captured. This has come up as a topic in #api (@mattmoor
  et al) and in conversations I've had with @MarkKropf.

[jchesterpivotal]

So:

• Cleanup a bit
• Start looking at capturing SHAs and digests
• Put it on a public Concourse so people can click around and look at it

[jchesterpivotal]

EOD notes:

• Pipeline now subs the image digest into the image: field, meaning that the Service controller recognises this as a new version. The basic workflow (git commit -> image built -> new version deployed) is done.
• The pipeline now captures the git SHA and image digest and puts these into an annotation on the Service. This was a nice-to-have.
• Did not get to putting the pipeline somewhere others could easily access it.
• Added some configurability bits and pieces.
• I am tempted to write a knative-service-resource to make the experience a bit smoother.

[jchesterpivotal]

Currently I am focused on spiking out a knative-service-resource (repo here). I still need to put it into a public Concourse, atm I don't have one prebaked to stand up on.

[jchesterpivotal]

I more or less finished spiking out the knative-service-resource. In the interests of timeliness I'm going to call this one done. I've proved the key elements:

• Reacting to a git push
• Building an image and pushing it to a registry
• Updating Configurations with the new image