-
Notifications
You must be signed in to change notification settings - Fork 83
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 compatibility for committime exporter #333
Conversation
git_host = build.metadata.labels.pelorusgithost | ||
git_project = build.metadata.labels.pelorusgitproject | ||
git_app = build.metadata.labels.pelorusgitapp | ||
git_protocol = build.metadata.labels.pelorusgitprotocol | ||
repo_url = ( | ||
git_protocol | ||
+ "://" | ||
+ git_host | ||
+ "/" | ||
+ git_project | ||
+ "/" | ||
+ git_app | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should break up git URLs in this way. There are a myriad of supported git url formats that are not covered by this structure, and to try to cover them all would be cumbersome and unnecessary. I would just stick to the two standard git parameters that are used all over the place:
git_url
- The full URL string in any formatgit_ref
- The branch or tag to be examined, if applicable
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@etsauer I initially approached the solution using labels. But labels have character restrictions for the value part. The idea is to improve this with an annotation to avoid dirty code like this one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using annotations makes sense. I'll add a BUILD_GIT_REPO_URI_ANNOTATION
env variable (or is that too long...)
We should probably use a namespaced default, right? Something like pelorus.konveyor.io/git-uri
? Or keep it simple with gitUri
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@KevinMGranger I was updating these values with a pipeline dynamically. Regarding the env variable, I think it is fine, I prefer it to be long and understandable rather than short and confusing.
Regarding the namespaced default, I think it's the same thing... keeping it simple can lead to confusion, I think having pelorus word in the name would indicate what it is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just few nits around shell to get started and understand what's happening in the project :)
edb82b9
to
2696ebc
Compare
pipeline_runs = pelorus.NoOpResourceInstance() | ||
|
||
# use a jsonpath expression to find all possible values for the app label | ||
jsonpath_str = f"$['items'][*]['metadata']['labels']['{app_label}']" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will break if app_label has single quotes in it for some reason. We could extract this part with plain python.
f4f843b
to
d4660f1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-
I think we should allow to install tkn and oc commands using Makefile dev-env to a separate PATH. This can however be different PR.
-
Should the project template be compatible as well with kubectl ? It means to use in the demo/tekton-demo-setup/02-project.yaml api version v1, similarly to:
https://github.com/redhat-cop/openshift-applier/blob/main/tests/files/templates/projectrequest.yml
Used to find the TaskRun that did the git checkout. | ||
""" | ||
pipeline_resource = self._kube_client.resources.get( | ||
api_version="tekton.dev/v1beta1", kind="Pipeline" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As in previous comment. I do think such api_versions should be hidden in the function body.
else: | ||
return NotImplemented | ||
|
||
def __repr__(self): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should you define __str__(self)
as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need to double check how these are used within the openshift library. I think I was unsure if __str__
should transparently use the underlying string, or use __repr__
.
Few more issues found with the script (using bash as shell on Fedora):
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Addressed your comments, looks like I have a little more work to do.
commit_sha = spec.revision.git.commit | ||
metric.committer = spec.revision.git.author.name | ||
else: | ||
# TODO: check for existence, allow user customization? Annotation instead? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call. I missed the UNKNOWN_AUTHOR
part as well-- I think we can just leave it out, but I need to double check Grafana/Prometheus.
else: | ||
return NotImplemented | ||
|
||
def __repr__(self): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need to double check how these are used within the openshift library. I think I was unsure if __str__
should transparently use the underlying string, or use __repr__
.
To summarize the remaining work:
|
Look for tekton data in standard locations. Add various utility / helper functions.
While we should make a broader error management strategy, this is here while tekton support is in preview.
Also fix referring to wrong FQDN attribute name
- use TypedStrings where possible to avoid previous errors - filter to only use successful pipeline runs - Rename many variables to be more clear and semantically correct - Avoid passing around names when already present in objects to reduce errors
@KevinMGranger: PR needs rebase. 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. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: KevinMGranger 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 |
@KevinMGranger: The following test failed, say
Full PR test history. Your PR dashboard. 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. I understand the commands that are listed here. |
Because tekton pipelines could be customized to do anything, supporting this by guessing isn't worth the technical cost. We've decided that the best course of action is to annotate the resulting build with the required info, which was implemented with PR #498. It also solves the problem in issue #317 at the same time! What would make tekton "support" easier is documenting how you might label the resulting build, and including an example of that. We already have demo code in the repo, so we'll likely use that. |
copied from #327
Describe the behavior changes introduced in this PR
Adds the ability to get git commit information from Tekton runs.
It's a good enough implementation for "technology preview" status. There are open questions about how to extract the right information when there's near infinite flexibility in making a pipeline.
Right now, it tries to follow the (I believe) most common usage patterns:
git-checkout
ClusterTask
that comes with TektonTaskRun
with ataskResult
namedIMAGE_DIGEST
TaskRun
withIMAGE
orIMAGE_NAME
as a param, following patterns from various s2i and buildah tasksI'm sure we'll need to figure out a way to add some flexibility. I've started exploring some possible solutions while experimenting with this, but that should come later.
Special thanks to @jlozano-rh for starting the work on this.
Linked Issues?
resolves #224
Testing Instructions
./demo/demo-tekton $URL_FOR_FORK
.@redhat-cop/mdt
Remaining Work
unable to recognize no matches for kind "Pipeline" in version "tekton.dev/v1beta1"