Organize samples

[SaschaSchwarze0]

Samples consist of two pieces:

• A source code repository
• A build CR, and for completeness, a buildrun CR

As of today, we have the CR samples in the samples directory. In, addition, for e2e tests, more CRs are in the test/data directory. That's fine for now.

Our sample code repositories are distributed across the planet. I suggest to bring them into the shipwright-io organization to mitigate that somebody removes the repos.

There are several ways to setup these repos. Putting together some options.

(1) A single samples repository named samples with a directory structure containing the sample code

(+) A single visible has good visibility
(-) Can become large. A lot of unnecessary files will be cloned for a build run.
(-) Does not work for build strategies that do not yet / can never support the contextDir feature. Not sure if we have some.

(2) One repository for each strategy named samples-{strategy}, may or may not contain sub-directories for different languages, e. g. sample-docker or sample-buildpacks

(+) Good for somebody who specifically looks how the sources for a specific strategy need to be prepared.
(-) Does not work for build strategies that do not yet / can never support the contextDir feature. Not sure if we have some.

(3) One repository for each language named sample-{language} (e. g. sample-java). Sample is built in a way supporting multiple strategies (specifically thinking about docker and buildpacks)

(+) Good for somebody who specifically looks for how the sources for a specific language can be built and who does not know much about the strategies
(+) Is small which will speed up e2e tests that use the repo.
(-) Can be confusing because it will contain a Dockerfile that is needed for a docker build but unnecessary for buildpacks. And will contain a buildpack.yml to configure certain buildpack details but that file is not relevant for the docker build.

[adambkaplan]

If the samples are going to include source code to build, then I am inclined to go with option 3. I really like the idea of having multiple build strategies highlighted with the same set of source code. Being able to pick and choose build strategies is the "killer feature" IMO.

We should probably restrict the number of sample-xxx repositories to two or three languages - perhaps Java, NodeJS, and Python?

I also think we should use example-xxx instead of sample - a sample is generic, an example is specific.

[adambkaplan]

This is an "option 3" example I cooked up today: https://github.com/adambkaplan/shipwright-example-nodejs

[zhangtbj]

I think we should have both option 2 and option 3 in our new org: https://github.com/shipwright-io

For different types of example and for different tests.

[zhangtbj]

Hi @adambkaplan or @qu1queee ,

I think we can go head moving the samples to our Shipwright org for v0.4.0

As we discussed in the meeting, we planed to create some separate repos for different source.

Like:

• https://github.com/SaschaSchwarze0/npm-simple
• [email protected]:qu1queee/newtaxi.git
• [email protected]:qu1queee/new-nodejs-ex.git
• https://github.com/SaschaSchwarze0/java-simple
• etc ...

I found I have the permission to create new repo like:
https://github.com/shipwright-io/samples-npm-simple

If no objection, we will open the new repos for these personal sources and switch in our e2e test.

[qu1queee]

@zhangtbj thanks. I think is fine, but I will prefer different names, something like:

• https://github.com/shipwright-io/samples-nodejs
• https://github.com/shipwright-io/samples-java
• https://github.com/shipwright-io/samples-go

[zhangtbj]

Agree, they are better names.

If all agree, we can create the new repos by following these names.

BTW, @qu1queee, I cannot delete this repo: https://github.com/shipwright-io/samples-npm-simple

Can you help delete it on your side?

[qu1queee]

@zhangtbj so I covered most of the work via #635. PR explains what I did, Im looking for help with:

• we are missing the repo for JAVA runtime and the source code there. @SaschaSchwarze0 maybe you can help here.

Im looking for feedback in general for the new repos:
- https://github.com/shipwright-io/sample-php
- https://github.com/shipwright-io/sample-ruby
- https://github.com/shipwright-io/sample-nodejs
- https://github.com/shipwright-io/sample-go

@adambkaplan fyi ^^

[SaschaSchwarze0]

we are missing the repo for JAVA runtime and the source code there. @SaschaSchwarze0 maybe you can help here.

I do not think I can create a repo, but if somebody creates one, I can add some Java sample to it.

Just noticed that I can create some repo. I created sample-java. Will add code to it later.

[SaschaSchwarze0]

Done. Is here: sample-java. @qu1queee

[adambkaplan]

Remaining item - we need to configure a private repository to facilitate our end to end test suites which clone source from private git repos.

[mattcui]

I would like to pick up this issue to add an e2e test for testing image building from a private repo.

[adambkaplan]

I've split the private repository work into a separate issue: #689

[adambkaplan]

/close

Given that we are tracking the private repository work into a separate issue, I think we can call this issue done.

[openshift-ci-robot]

@adambkaplan: Closing this issue.

In response to this:

/close

Given that we are tracking the private repository work into a separate issue, I think we can call this issue done.

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.