-
Notifications
You must be signed in to change notification settings - Fork 110
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
Tekton CI should comment on how to re-run tests #483
Comments
Stale issues rot after 30d of inactivity. /lifecycle rotten Send feedback to tektoncd/plumbing. |
Rotten issues close after 30d of inactivity. /close Send feedback to tektoncd/plumbing. |
@tekton-robot: Closing this issue. In response to this:
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. |
/remove-lifecycle rotten |
@vdemeester: Reopened this issue. In response to this:
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. |
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
Stale issues rot after 30d of inactivity. /lifecycle rotten Send feedback to tektoncd/plumbing. |
Rotten issues close after 30d of inactivity. /close Send feedback to tektoncd/plumbing. |
@tekton-robot: Closing this issue. In response to this:
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. |
/lifecycle frozen |
/assign |
This will be used as part of tektoncd/plumbing#483 in Tekton's own CI setup, and I think it could be generally useful for replicating behavior such as Prow's job failure comments. Those comments are deleted once the job completes next, with a new comment created for subsequent failures, so that the latest result is always towards the end of the comment list. Signed-off-by: Andrew Bayer <[email protected]>
This will be used as part of tektoncd/plumbing#483 in Tekton's own CI setup, and I think it could be generally useful for replicating behavior such as Prow's job failure comments. Those comments are deleted once the job completes next, with a new comment created for subsequent failures, so that the latest result is always towards the end of the comment list. Signed-off-by: Andrew Bayer <[email protected]>
This will be used as part of tektoncd/plumbing#483 in Tekton's own CI setup, and I think it could be generally useful for replicating behavior such as Prow's job failure comments. Those comments are deleted once the job completes next, with a new comment created for subsequent failures, so that the latest result is always towards the end of the comment list. Signed-off-by: Andrew Bayer <[email protected]>
This will be used as part of tektoncd/plumbing#483 in Tekton's own CI setup, and I think it could be generally useful for replicating behavior such as Prow's job failure comments. Those comments are deleted once the job completes next, with a new comment created for subsequent failures, so that the latest result is always towards the end of the comment list. Signed-off-by: Andrew Bayer <[email protected]>
This will be used as part of tektoncd/plumbing#483 in Tekton's own CI setup, and I think it could be generally useful for replicating behavior such as Prow's job failure comments. Those comments are deleted once the job completes next, with a new comment created for subsequent failures, so that the latest result is always towards the end of the comment list. Signed-off-by: Andrew Bayer <[email protected]>
This will be used as part of tektoncd/plumbing#483 in Tekton's own CI setup, and I think it could be generally useful for replicating behavior such as Prow's job failure comments. Those comments are deleted once the job completes next, with a new comment created for subsequent failures, so that the latest result is always towards the end of the comment list. Signed-off-by: Andrew Bayer <[email protected]>
This will be used as part of tektoncd/plumbing#483 in Tekton's own CI setup, and I think it could be generally useful for replicating behavior such as Prow's job failure comments. Those comments are deleted once the job completes next, with a new comment created for subsequent failures, so that the latest result is always towards the end of the comment list. Signed-off-by: Andrew Bayer <[email protected]>
This will be used as part of tektoncd/plumbing#483 in Tekton's own CI setup, and I think it could be generally useful for replicating behavior such as Prow's job failure comments. Those comments are deleted once the job completes next, with a new comment created for subsequent failures, so that the latest result is always towards the end of the comment list. Signed-off-by: Andrew Bayer <[email protected]>
This will be used as part of tektoncd/plumbing#483 in Tekton's own CI setup, and I think it could be generally useful for replicating behavior such as Prow's job failure comments. Those comments are deleted once the job completes next, with a new comment created for subsequent failures, so that the latest result is always towards the end of the comment list. Signed-off-by: Andrew Bayer <[email protected]>
Part of tektoncd#483 This custom task is meant to be used alongside PR status report updates to add/update/delete a comment equivalent to the Prow one listing job failures with links to logs and the command to re-test. I initially made an attempt to update the `github-add-comment` task in the catalog to do this (tektoncd/catalog#1051) but decided that a custom task frankly made a lot more sense. Its behavior is a pretty direct emulation of how Prow and Lighthouse do this, looking for existing comments by the bot user with a given tag in the comment, and updating/deleting that comment if it exists, creating a new comment otherwise. It's a bit simplified, and instead of using `ProwJob`s to know what should still be in the comment and what should be removed, it specifically just adds or removes the specific job it's reporting on while preserving whatever else was there. Signed-off-by: Andrew Bayer <[email protected]>
Part of tektoncd#483 This custom task is meant to be used alongside PR status report updates to add/update/delete a comment equivalent to the Prow one listing job failures with links to logs and the command to re-test. I initially made an attempt to update the `github-add-comment` task in the catalog to do this (tektoncd/catalog#1051) but decided that a custom task frankly made a lot more sense. Its behavior is a pretty direct emulation of how Prow and Lighthouse do this, looking for existing comments by the bot user with a given tag in the comment, and updating/deleting that comment if it exists, creating a new comment otherwise. It's a bit simplified, and instead of using `ProwJob`s to know what should still be in the comment and what should be removed, it specifically just adds or removes the specific job it's reporting on while preserving whatever else was there. Signed-off-by: Andrew Bayer <[email protected]>
Part of tektoncd#483 This custom task is meant to be used alongside PR status report updates to add/update/delete a comment equivalent to the Prow one listing job failures with links to logs and the command to re-test. I initially made an attempt to update the `github-add-comment` task in the catalog to do this (tektoncd/catalog#1051) but decided that a custom task frankly made a lot more sense. Its behavior is a pretty direct emulation of how Prow and Lighthouse do this, looking for existing comments by the bot user with a given tag in the comment, and updating/deleting that comment if it exists, creating a new comment otherwise. It's a bit simplified, and instead of using `ProwJob`s to know what should still be in the comment and what should be removed, it specifically just adds or removes the specific job it's reporting on while preserving whatever else was there. Signed-off-by: Andrew Bayer <[email protected]>
Part of tektoncd#483 This custom task is meant to be used alongside PR status report updates to add/update/delete a comment equivalent to the Prow one listing job failures with links to logs and the command to re-test. I initially made an attempt to update the `github-add-comment` task in the catalog to do this (tektoncd/catalog#1051) but decided that a custom task frankly made a lot more sense. Its behavior is a pretty direct emulation of how Prow and Lighthouse do this, looking for existing comments by the bot user with a given tag in the comment, and updating/deleting that comment if it exists, creating a new comment otherwise. It's a bit simplified, and instead of using `ProwJob`s to know what should still be in the comment and what should be removed, it specifically just adds or removes the specific job it's reporting on while preserving whatever else was there. Signed-off-by: Andrew Bayer <[email protected]>
Part of tektoncd#483 This custom task is meant to be used alongside PR status report updates to add/update/delete a comment equivalent to the Prow one listing job failures with links to logs and the command to re-test. I initially made an attempt to update the `github-add-comment` task in the catalog to do this (tektoncd/catalog#1051) but decided that a custom task frankly made a lot more sense. Its behavior is a pretty direct emulation of how Prow and Lighthouse do this, looking for existing comments by the bot user with a given tag in the comment, and updating/deleting that comment if it exists, creating a new comment otherwise. It's a bit simplified, and instead of using `ProwJob`s to know what should still be in the comment and what should be removed, it specifically just adds or removes the specific job it's reporting on while preserving whatever else was there. Signed-off-by: Andrew Bayer <[email protected]>
Part of #483 This custom task is meant to be used alongside PR status report updates to add/update/delete a comment equivalent to the Prow one listing job failures with links to logs and the command to re-test. I initially made an attempt to update the `github-add-comment` task in the catalog to do this (tektoncd/catalog#1051) but decided that a custom task frankly made a lot more sense. Its behavior is a pretty direct emulation of how Prow and Lighthouse do this, looking for existing comments by the bot user with a given tag in the comment, and updating/deleting that comment if it exists, creating a new comment otherwise. It's a bit simplified, and instead of using `ProwJob`s to know what should still be in the comment and what should be removed, it specifically just adds or removes the specific job it's reporting on while preserving whatever else was there. Signed-off-by: Andrew Bayer <[email protected]>
Closes tektoncd#483 I could have added a new `TriggerTemplate`, but it made more sense to just turn the existing `tekton-ci-github-check-end` into a `PipelineRun`. I did have to add a couple new parameters - the bare repo name (since I wrote up the PR commenter to have the org as a global configuration), and a boolean for pass/fail. It may make sense to tweak the PR commenter to handle `org/repo` instead of just `repo`, and `"success"` or `"failure"` instead of `true` or `false`, but I thought I'd wait to see what people think. =) Signed-off-by: Andrew Bayer <[email protected]>
Closes tektoncd#483 I could have added a new `TriggerTemplate`, but it made more sense to just turn the existing `tekton-ci-github-check-end` into a `PipelineRun`. I did have to add a couple new parameters - the bare repo name (since I wrote up the PR commenter to have the org as a global configuration), and a boolean for pass/fail. It may make sense to tweak the PR commenter to handle `org/repo` instead of just `repo`, and `"success"` or `"failure"` instead of `true` or `false`, but I thought I'd wait to see what people think. =) Signed-off-by: Andrew Bayer <[email protected]>
Closes #483 I could have added a new `TriggerTemplate`, but it made more sense to just turn the existing `tekton-ci-github-check-end` into a `PipelineRun`. I did have to add a couple new parameters - the bare repo name (since I wrote up the PR commenter to have the org as a global configuration), and a boolean for pass/fail. It may make sense to tweak the PR commenter to handle `org/repo` instead of just `repo`, and `"success"` or `"failure"` instead of `true` or `false`, but I thought I'd wait to see what people think. =) Signed-off-by: Andrew Bayer <[email protected]>
Expected Behavior
Similar to what prow does, when test job fail they should report on how to re-run them.
The comment should only be posted once (old one can be deleted), and should include all checks managed by Tekton.
Certain checks (like the kind label check) may want to display extra text.
Actual Behavior
No comment is displayed.
Additional Info
The text was updated successfully, but these errors were encountered: