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

Fill in more data for started.json in initupload #11304

Merged
merged 1 commit into from Feb 19, 2019

Conversation

krzyzacy
Copy link
Member

@krzyzacy krzyzacy commented Feb 14, 2019

(trying out the draft PR feature?)

/assign @fejta
cc @cjwagner @stevekuznetsov

resolve most of #10544 beside the node name

@k8s-ci-robot k8s-ci-robot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Feb 14, 2019
@k8s-ci-robot k8s-ci-robot added area/prow Issues or PRs related to prow area/prow/initupload Issues or PRs related to prow's initupload component area/prow/pod-utilities Issues or PRs related to prow's pod-utilities component area/prow/sidecar Issues or PRs related to prow's sidecar component sig/testing Categorizes an issue or PR as relevant to SIG Testing. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. approved Indicates a PR has been approved by an approver from all required OWNERS files. labels Feb 14, 2019
@stevekuznetsov
Copy link
Contributor

Love the direction here

@cjwagner
Copy link
Member

Looks good so far, the organization is great.
"backfill" had me confused for a second though. This isn't backfilling data into existing started.json files, but rather adding more fields to files created going forward.

@krzyzacy
Copy link
Member Author

I thought backfill means fill in something we are missing from before, but please bikeshed my English :-)

I'll add a few more test cases and handle #10359 in a separate PR :-)

@krzyzacy krzyzacy changed the title [WIP] backfill data in started.json Fill in more data for started.json in initupload Feb 15, 2019
@k8s-ci-robot k8s-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Feb 15, 2019
Copy link
Contributor

@fejta fejta left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm
/hold

} else if len(spec.ExtraRefs) > 0 {
finished.Revision = getRevisionFromRef(&spec.ExtraRefs[0])
}
finished.Revision = downwardapi.GetRevisionFromSpec(spec)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like us to drop Revision as it is not useful:

  • job-version in finished.json needs to be set to what the job configures at runtime and puts in metadata.json
  • repo-version should be in started.json, set from the refs
  • we should have some other field that does a more complex recording of the refs (either repos or else a new refs field).

Revision just duplicates repo-version in the wrong location.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added that when we were thinking we should only keep a timestamp in started.json. Since I also changed places like testgrid and gubernator, I need to make some clean-up PRs to follow up.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • we should have some other field that does a more complex recording of the refs (either repos or else a new refs field).

Agreed, although I'm not sure that repos is sufficient. The complete ref data also includes ref names and any pull request numbers and SHAs. Including the complete serialized list of Refs structs in a refs field may be the best option.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does that mean testgrid need to know a prow struct? Note that we also need to handle other hand-crafted started.json :-)

Maybe we can dump the refs into metadata?

func specToStarted(spec *downwardapi.JobSpec) gcs.Started {
started := gcs.Started{
Timestamp: time.Now().Unix(),
RepoVersion: downwardapi.GetRevisionFromSpec(spec),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this should be RepoCommit, rather than RepoVersion?

meta['repo-commit'] = commit.strip()

Looks like I goofed here:

RepoVersion string `json:"repo-version,omitempty"`

And checking testgrid's internal updater it has been looking for repo-commit, job-version and/or version since 2017. So we should use repo-commit, not repo-version.

which somewhat makes sense, as repo-commit is a git commit, whereas job-version is a random string set by the job.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hold on hold on - this is not true at all - see

data['repo-version'] = version
, repo-commit is a field in metadata in finished.json instead of started.json

although this repo-version in started.json is 👎 (

def find_version(call):
"""Determine and return the version of the build."""
# TODO(fejta): once job-version is functional switch this to
# git rev-parse [--short=N] HEAD^{commit}
version_file = 'version'
if os.path.isfile(version_file):
# e2e tests which download kubernetes use this path:
with open(version_file) as fp:
return fp.read().strip()
version_script = 'hack/lib/version.sh'
if os.path.isfile(version_script):
cmd = [
'bash', '-c', (
"""
set -o errexit
set -o nounset
export KUBE_ROOT=.
source %s
kube::version::get_version_vars
echo $KUBE_GIT_VERSION
""" % version_script)
]
return call(cmd, output=True).strip()
return 'unknown'
) - so - I guess I can just do a rev-parse like #11330?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should link this thread to my "WTF are these fields even" issue 😆

@k8s-ci-robot k8s-ci-robot added do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. lgtm "Looks good to me", indicates that a PR is ready to be merged. labels Feb 15, 2019
@k8s-ci-robot
Copy link
Contributor

LGTM label has been added.

Git tree hash: bfa79f35e4144f12fdb42c972d252e94ad837b40

@k8s-ci-robot k8s-ci-robot added area/testgrid and removed lgtm "Looks good to me", indicates that a PR is ready to be merged. labels Feb 15, 2019
@krzyzacy
Copy link
Member Author

/hold

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: krzyzacy

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

@krzyzacy
Copy link
Member Author

/hold cancel
Kept RepoVersion

@k8s-ci-robot k8s-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Feb 18, 2019
Copy link
Contributor

@fejta fejta left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Feb 19, 2019
@k8s-ci-robot
Copy link
Contributor

LGTM label has been added.

Git tree hash: bfa79f35e4144f12fdb42c972d252e94ad837b40

@krzyzacy
Copy link
Member Author

/retest

@krzyzacy
Copy link
Member Author

/retest

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. area/prow/initupload Issues or PRs related to prow's initupload component area/prow/pod-utilities Issues or PRs related to prow's pod-utilities component area/prow/sidecar Issues or PRs related to prow's sidecar component area/prow Issues or PRs related to prow area/testgrid cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged. sig/testing Categorizes an issue or PR as relevant to SIG Testing. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants