I suspect this is intentional [1] but I cannot update any artifacts (name: Job Info in particular in this case) I can create new artifacts but that is not helpful at this point because they have no UI... I suspect overriding the "blob" here would a decent fix. 1 : https://github.com/mozilla/treeherder-service/blob/52a653911e450fb5c5e9359438fd90a87c85b82a/treeherder/model/sql/jobs.json#L187-L203

To be clear my use case here is I would like to add artifacts as taskcluster generates them (we generate some at the beginning and some at the end but maybe dynamically in the future) so either updating the blob or being able to insert visible artifacts as job details works for me... I will dig into what the buildbot integration does now.

Failing test showing the kind of operation I am trying.

More context (mostly for me) It appears the primary ingestion point for the "Job Info" artifact is the logparser (which only runs after the job is complete). There seems two easy paths to fix this. 1. If "name" is really supposed to be unique actually make it unique in the schema (which allows insert on duplicate key/replace) 2. Remove the duplicate checks and allow multiple artifacts with the same name (and update the UI to work accordingly) this is attractive since it avoids the schema update and fixes another issue for us which is we would ideally like to insert our artifacts into the job info as they are generated rather then only at completion. 3. (least attractive to me) Is to add a new log parser for taskcluster as we do log the artifact completion events but this does not help other projects (which I do care about in the near future which may want to do similar things)

UI side for approach #2 (multiple artifacts with the same name)

Comment on attachment 8500088 [details] https://github.com/mozilla/treeherder-service/pull/240 Approach #2 Server Side. I am happy to write up a patch for the first approach (which looks closer to the original intention of the dup checks) but this is probably way easier to deploy and is actually closer to what I want.. This makes it easy to append new 'Job Info' (this can be a double edge sword if people use this with job submission probably)

Commits pushed to master at https://github.com/mozilla/treeherder-ui https://github.com/mozilla/treeherder-ui/commit/d7f59aac685db6ff265ef79f3502126a00029169 Bug 1077888 - Allow multiple 'Job Info' artifacts https://github.com/mozilla/treeherder-ui/commit/448a46294aa926eb7228dc6be792c81afd29f2ee Merge pull request #217 from lightsofapollo/bug-1077888 Bug 1077888 - Allow multiple 'Job Info' artifacts

Status update: not forgotten! We're still resolving some more critical infrastructure and resilience problems, but will get to this as soon as we can. It's not a trivial review, since we have to make sure it makes sense from a larger architectural perspective.

:lightsofapollo I'm sorry it took so long to review it. The problem wasn't the code itself but the potential issues this change brings in. The data ingestion system on treeherder is currently ingesting pending and running jobs over and over from buildapi. With this setup the same job could be ingested more than once (together with its artifacts). I'd love to change this behaviour, but that would require quite a bit of refactoring and time. At the moment we don't have that time. As a short term solution I was thinking of adding a version column to the artifact table and use that to support your use case. How does that sound to you?

So newer versions would displace older ones? (That would work for me)... I am fine with any solution that lets us update the artifacts for a job.

Commits pushed to master at https://github.com/mozilla/treeherder https://github.com/mozilla/treeherder/commit/5134006ced52f221c9d00fb2f520840df68dbb68 Bug 1077888 - Allow multiple 'Job Info' artifacts https://github.com/mozilla/treeherder/commit/a8d051f0ebfeba0258d7b38cdd36d2fc3c0a9afb Merge pull request #217 from lightsofapollo/bug-1077888 Bug 1077888 - Allow multiple 'Job Info' artifacts