Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve TaskRun workspaces documentation #2632

Merged

Conversation

jlpettersson
Copy link
Member

Changes

This commit contains similar changes for the TaskRun section as what was done for the PipelineRun section in #2521

  • We did not provide a full example of a TaskRun definition under "Examples of TaskRun definition using Workspaces". This commit add a full example of a TaskRun definition.

  • Examples of how to use different volume sources already exists under "Specifying VolumeSources in Workspaces", add a link to that section instead of having the same examples under the TaskRun section.

  • A few broken links in the table-of-contents are fixed.

/kind documentation

Submitter Checklist

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

See the contribution guide for more details.

Double check this list of stuff that's easy to miss:

Reviewer Notes

If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.

@tekton-robot tekton-robot added the kind/documentation Categorizes issue or PR as related to documentation. label May 16, 2020
@tekton-robot tekton-robot added the size/M Denotes a PR that changes 30-99 lines, ignoring generated files. label May 16, 2020
@tekton-robot
Copy link
Collaborator

Hi @jlpettersson. 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.

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.

@tekton-robot tekton-robot added the needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. label May 16, 2020
@tekton-robot
Copy link
Collaborator

This PR cannot be merged: expecting exactly one kind/ label

Available kind/ labels are:

kind/bug: Categorizes issue or PR as related to a bug.
kind/flake: Categorizes issue or PR as related to a flakey test
kind/cleanup: Categorizes issue or PR as related to cleaning up code, process, or technical debt.
kind/design: Categorizes issue or PR as related to design.
kind/documentation: Categorizes issue or PR as related to documentation.
kind/feature: Categorizes issue or PR as related to a new feature.
kind/misc: Categorizes issue or PR as a miscellaneuous one.

@jlpettersson
Copy link
Member Author

This PR cannot be merged: expecting exactly one kind/ label

This was unexpected. The PR had a kind-label, but with the syntax slash-kind, and that is the syntax used in other PRs. And the "Info"-section describes other label-syntax than is used in other PRs

check-pr-has-kind-label — This PR has exactly one kind/ label

This check is green

tekton-robot added the kind/documentation label

And the tekton-robot correctly added a label.

This commit contains similar changes for the TaskRun section as what was done for the PipelineRun section in tektoncd#2521

- We did not provide a full example of a TaskRun definition under "Examples of `TaskRun` definition using `Workspaces`"
  This commit add a full example of a TaskRun definition.

- Examples of how to use different volume sources already exists under "Specifying `VolumeSources` in `Workspaces`",
  add a link to that section instead of having the same examples under the TaskRun section.

- A few broken links in the table-of-contents are fixed.

/kind documentation
@jlpettersson jlpettersson force-pushed the improve_taskrun_workspaces_doc branch from 235b829 to cb3ec93 Compare May 17, 2020 00:33
@vdemeester
Copy link
Member

/ok-to-test

@tekton-robot tekton-robot added ok-to-test Indicates a non-member PR verified by an org member that is safe to test. and removed needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels May 18, 2020
@vdemeester
Copy link
Member

/cc @sbwsg

@tekton-robot tekton-robot requested a review from a user May 18, 2020 09:12
@afrittoli
Copy link
Member

This PR cannot be merged: expecting exactly one kind/ label

This was unexpected. The PR had a kind-label, but with the syntax slash-kind, and that is the syntax used in other PRs. And the "Info"-section describes other label-syntax than is used in other PRs

check-pr-has-kind-label — This PR has exactly one kind/ label

This check is green

tekton-robot added the kind/documentation label

And the tekton-robot correctly added a label.

The check for the label is run on the "sync", "pull_request" and add/remove label events. When the events are processed the PR does not yet have a label, so it posts the comment and sets the check to not-passed. In parallel the "kind" bot adds the label, triggers the check again, and sets the check to passed.

We don't have a mechanism in place to delete the old comment once that happens. That would require us to have a memory of what the comment was, or perhaps add some invisible metadata into the comment, so we can delete it.

Would you mind filing an issue on plumbing for this?

@tekton-robot
Copy link
Collaborator

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: sbwsg

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:

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

@tekton-robot tekton-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label May 18, 2020
@vdemeester
Copy link
Member

/lgtm

@tekton-robot tekton-robot added the lgtm Indicates that a PR is ready to be merged. label May 18, 2020
@tekton-robot tekton-robot merged commit f8a61ef into tektoncd:master May 18, 2020
jlpettersson added a commit to jlpettersson/community that referenced this pull request May 19, 2020
Jonas has recently become a regularly contributor. He started with adding a minor [_missing_ `omitempty`](tektoncd/pipeline#2301) and then [proposed some ideas](tektoncd/pipeline#1986 (comment)) around workspaces and PersistentVolumeClaim creation and continued to [elaborate around those ideas](tektoncd/pipeline#1986 (comment)). A sunny day a few days later, he also submitted an [extensive implementation for volumeClaimTemplate](tektoncd/pipeline#2326), corresponding to the idea discussions.

A few days later submitted a [small refactoring PR](tektoncd/pipeline#2392), and he also listened to community members that [proposed changes](tektoncd/pipeline#2450) to his implementation about volumeClaimTemplates and did an [implementation for that proposal](tektoncd/pipeline#2453).

A rainy day, he also wrote [technical documentation about PVCs](tektoncd/pipeline#2521) including adding an example that caused _flaky_ integration tests for the whole community during multiple days. When he understood his mistake, he submitted a [removal of the example](tektoncd/pipeline#2546) that caused flaky tests.

He has also put his toe into Tekton Catalog and [contributed to the buildah task](tektoncd/pipeline#2546).

This has followed, mostly with more PRs to the Pipeline project:

- tektoncd/pipeline#2460
- tektoncd/pipeline#2491
- tektoncd/pipeline#2502
- tektoncd/pipeline#2506
- tektoncd/pipeline#2632
- tektoncd/pipeline#2633
- tektoncd/pipeline#2634
- tektoncd/pipeline#2636
- tektoncd/pipeline#2601
- tektoncd/pipeline#2630

Jonas is excited about the great community around Tekton and the project! He now would like to join the org.
tekton-robot pushed a commit to tektoncd/community that referenced this pull request May 20, 2020
Jonas has recently become a regularly contributor. He started with adding a minor [_missing_ `omitempty`](tektoncd/pipeline#2301) and then [proposed some ideas](tektoncd/pipeline#1986 (comment)) around workspaces and PersistentVolumeClaim creation and continued to [elaborate around those ideas](tektoncd/pipeline#1986 (comment)). A sunny day a few days later, he also submitted an [extensive implementation for volumeClaimTemplate](tektoncd/pipeline#2326), corresponding to the idea discussions.

A few days later submitted a [small refactoring PR](tektoncd/pipeline#2392), and he also listened to community members that [proposed changes](tektoncd/pipeline#2450) to his implementation about volumeClaimTemplates and did an [implementation for that proposal](tektoncd/pipeline#2453).

A rainy day, he also wrote [technical documentation about PVCs](tektoncd/pipeline#2521) including adding an example that caused _flaky_ integration tests for the whole community during multiple days. When he understood his mistake, he submitted a [removal of the example](tektoncd/pipeline#2546) that caused flaky tests.

He has also put his toe into Tekton Catalog and [contributed to the buildah task](tektoncd/pipeline#2546).

This has followed, mostly with more PRs to the Pipeline project:

- tektoncd/pipeline#2460
- tektoncd/pipeline#2491
- tektoncd/pipeline#2502
- tektoncd/pipeline#2506
- tektoncd/pipeline#2632
- tektoncd/pipeline#2633
- tektoncd/pipeline#2634
- tektoncd/pipeline#2636
- tektoncd/pipeline#2601
- tektoncd/pipeline#2630

Jonas is excited about the great community around Tekton and the project! He now would like to join the org.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. kind/documentation Categorizes issue or PR as related to documentation. lgtm Indicates that a PR is ready to be merged. ok-to-test Indicates a non-member PR verified by an org member that is safe to test. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants