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
Make cloneref expose baseSHA if not specified in config #10359
Comments
Nooooo!!!! We want a new type of job -- a ref-driven periodic. We should stop having two types of ref jobs. It breaks all sorts of mental models when half of the refs are declarative from spec and half are resolved at run-time -.- |
We probably want one type of job instead of more types of jobs 😂 |
Periodics that use |
$ git ls-remote https://github.com/kubernetes/test-infra master
d3cef13 refs/heads/master
https://git-scm.com/docs/git-ls-remote.html
…On Wed, Dec 5, 2018 at 7:55 PM Cole Wagner ***@***.***> wrote:
Periodics that use ExtraRefs are ref-driven periodics. We could make Prow
components populate the baseSHA for ExtraRefs like trigger does for
presubmits' Refs. Currently we determine the baseSHA via the GitHub API
so unless we switch to using the git client, this would require components
like horologium to use a GitHub token 👎 .
Is there a git command to look up the SHA for a remote refname without
cloning the repo?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#10359 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA4Bq6goDJY9aY-gDNZwwwPOic6gKiYpks5u2JUcgaJpZM4ZFmts>
.
|
good to know! we probably also need to handle private repos on top of that. |
/assign |
Not technically true. They're driven but not at the specific commit level. The ref is still resolved at run-time tomorrow. |
hummm, after a closer look, it's too late to resolve the remote refs in sidecar if we use |
We should implement a new type of job. We should not hack this backwards. |
@stevekuznetsov test-infra/prow/apis/prowjobs/v1/types.go Line 453 in 27184a2
We just don't have logic in horologium to resolve the SHA before creating the job. |
in pjutils? that's the only unified place I can think of.. |
so, just pre-check: do all of the controller images have git? |
No, all controllers that create jobs now need to use the git-base image like test-infra/prow/cmd/hook/BUILD.bazel Line 8 in 43dc577
|
Lets get @stevekuznetsov's thoughts before we go ahead with this though. |
yeah, implementation itself sounds pretty straight forward. |
I meant that we don't set SHA today, not that we can't. I agree that getting var refs prow.Refs
switch job.Type:
case prow.Presubmit:
refs = job.Refs
case prow.Periodic:
refs = job.ExtraRefs[0] Seems like we could do better and have a type of job that always has |
If it's breaking it might be safer to create a new job type |
I don't know of any jobs that this would break and I would think it is ok as we are just populating a previously empty field. I don't think we have anything checking that today. I think the ideal path forward would be to change the ProwJobs |
No, wouldn't we just always honor |
Always having a slice would also work |
Ah I see what you are saying. I still don't really like that pattern because we still have two fields that define refs. Some logic to handle both var allRefs []kube.Refs
if spec.Refs != nil {
allRefs = append(allRefs, *spec.Refs)
}
allRefs = append(allRefs, spec.ExtraRefs...) In any case it sounds like we can go forward with having Prow controllers populate the ExtraRefs' baseSHAs if they are unspecified? I think we should probably be doing that either way and that will unblock Sen. We can watch to see if any periodics are affected in case some job is doing something strange. |
cc @BenTheElder |
We need to solve this as we are starting to migrate verify/integration job onto podutils - technically we don't care extra_refs for presubmits (the short term goal is to show the commit number to testgrid), |
So now we are moving towards backfill the data into started/finished.json now, @stevekuznetsov wonder if the downstream spec is mutable when we are cloning? Or otherwise I'm thinking of we can make initupload understand clone-records.json? |
I don't think we should mutate the downstream spec from the job, even during the initial cloning step. If the downstream spec needs additional data I think it should be populated before the pod is scheduled. |
Unless we want to resolve master -> some sha within prow, that's unlikely. It can be resolved during cloning though. |
Yeah, I'm saying if we need the downstream spec to include the SHA then all Prow components that trigger jobs should resolve the SHA when creating the job. That sounds like a potentially annoying constraint to add to PJ creation though. |
yeah I can add some logic to make inituploader to understand fields from clone-records.json |
💯 |
🤞 |
Currently we can have
baseRef: master
with an emptybaseSHA
, for example, for periodic jobs specifies an extra_ref points to k/k master.Cloneref could potentially expose the actual baseSHA and make sidecar aware of the actual SHA so we can use the SHA instead of ref when record revision in finished.json.
/area prow
cc @cjwagner @BenTheElder @stevekuznetsov
The text was updated successfully, but these errors were encountered: