Hi Nick and Andrew, Thanks for the questions.
The job details panel in the UI will continue to display uploaded artifacts, the difference is we'll be retrieving them from taskcluster directly rather than storing them in JobDetails API and then retrieving them that way. I mentioned this in case anyone is relying on the JobDetails API specifically to get that information. > I don't see any slated replacement for print lines. A great deal of useful information is summarized in these lines (e.g., we dump libxul/classes.dex/and APK sizes using this mechanism -- or at least we did). What's happening here? We currently process data from the jobInfo and extra.artifacts properties of jobs we ingest (this goes into the JobDetails table). Can some of the data in TinderboxPrint lines be surfaced in the properties of jobs instead (or those aforementioned fields)? Or reported to Perfherder, if it consists of stats (some of which might already be via the PERFHERDER_DATA log lines)? What specific information are you needing to see? > As somebody who has dumped files to MOZ_UPLOAD_DIR and used the job detail tab to download those files (just this week, in fact!), but has only a vague idea of what the "taskcluster API" even is, let alone a "rootURL" or the rest of it, is there any introductory documentation about how I might retrieve files written to MOZ_UPLOAD_DIR? Am I going to have to write some kind of Python script to retrieve my files in the future? That GitHub issue seems to require a lot of background information that I do not have. You only need to make a change if you were using the JobDetails API specifically to retrieve the uploaded artifacts, either via a script or library. If that's not your use case, you can disregard :) Otherwise, this is the API: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/<taskId>/runs/0/artifacts <-- for all artifacts or with `/<artifactName>` to select just one specific artifact. We can set up a time to chat on slack/riot or video if you need guidance on implementation for use with a script or library. Sarah On Thu, Apr 9, 2020 at 9:05 PM Nicholas Alexander <nalexan...@mozilla.com> wrote: > Hello Sarah, others, > > On Thu, Apr 9, 2020 at 6:51 PM Sarah Clements <scleme...@mozilla.com> > wrote: > >> Hello, >> >> As part of maintenance work and performance improvements to Treeherder, >> we're making changes to some of the data that's stored in our database. On >> *April >> 30th*, we will no longer be retrieving uploaded artifacts for jobs and >> storing them in the JobDetail table. >> >> Uploaded artifacts can be retrieved via a taskcluster API, with the >> appropriate rootUrl, taskId and runId. TaskId and runId (synonymous with >> retryId in Treeherder) can be surfaced from any of our /jobs/ API's. See >> this >> <https://github.com/mnoorenberghe/mozscreenshots/issues/43#issue-592994567> >> for implementation details. >> >> We're also planning to deprecate the parsing and storage of >> TinderboxPrint log lines in the JobDetail table. They'll no longer be shown >> in Treeherder's job detail panel but you can still read them in the raw >> logs via the log-viewer. >> >> If you have any questions or concerns (or need a longer timeline to make >> changes that rely on this data), don't hesitate to reach out. >> > > I have worked with both of these APIs and been frustrated with them (and > filed tickets that are now being closed), so I'm pleased to see changes in > this area. However, I have some questions. > > Does the TH UI that exposes artifacts change as part of this? I.e., does > it get harder to find the package produced by a build job? > > I don't see any slated replacement for print lines. A great deal of > useful information is summarized in these lines (e.g., we dump > libxul/classes.dex/and APK sizes using this mechanism -- or at least we > did). What's happening here? > > Best, > Nick > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
