Closed
Bug 1226244
Opened 9 years ago
Closed 8 years ago
Switch to namespaced artifact paths
Categories
(Taskcluster :: Services, defect)
Taskcluster
Services
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: dustin, Assigned: dustin)
References
Details
(this may turn into a tracker) The namespace docs say that `public/*` is public, `private/*` is only slightly less than public (basically any mozilla employee can view it), and that artifacts that require actual care in their visibility should be under `projects/<project>` So, let's see where we're using private artifacts, and update those to use the correct paths.
Comment 1•9 years ago
|
||
As far as I'm aware, the main spot where we use them is in the device builds and tests. I believe most of the build stuff is right now put under "private/build/*" and the stuff for device tests is unfortunately under private/*
Comment 2•9 years ago
|
||
Generally, I think we should encourage people to use something other that private/ if they need more security than being behind NDA. The only thing I can imagine is that some day the security team might want to ensure their artifacts are restricted to only a small team.
Assignee | ||
Comment 3•9 years ago
|
||
That's the idea promulgated in the namespaces doc.
Assignee | ||
Comment 4•8 years ago
|
||
Looking at the scopes: dustin@hopper ~ $ curl https://auth.taskcluster.net/v1/clients/ | jq '.[] | [.roleId, .expandedScopes]' | grep artifact | sort -u "queue:create-artifact:*", "queue:create-artifact:private/dummy-test-provisioner.log", "queue:create-artifact:public/*", "queue:create-artifact:public/dummy-test-provisioner.log", "queue:create-artifact:public/logs/all_commands.log", "queue:create-artifact:public/logs/command_000000.log", "queue:create-artifact:public/logs/command_000000.log.live", "queue:create-artifact:public/node_modules.tar.gz", "queue:create-artifact:SampleArtifacts/_/X.txt", "queue:get-artifact:*" "queue:get-artifact:private/*" "queue:get-artifact:private/*", "queue:get-artifact:private/build/*" "queue:get-artifact:private/build/sources.xml", "queue:get-artifact:private/docker-worker/*", "queue:get-artifact:/private/docker-worker-tests/*", "queue:get-artifact:private/docker-worker-tests/*", "queue:get-artifact:private/dummy-test-provisioner.log", "queue:get-artifact:project/rust/*", "queue:get-artifact:public/logs/all_commands.log", "queue:get-artifact:public/logs/command_000000.log", "queue:get-artifact:SampleArtifacts/_/X.txt", so for the most part, we're already in compliance here (the weird stuff is all for tests). In the gecko tree: dustin@dustin-moz-devel ~/p/m-c (bug1255644) $ grep -r -A1 artifacts: testing/taskcluster/tasks/ testing/taskcluster/tasks/decision/branch.yml: artifacts: testing/taskcluster/tasks/decision/branch.yml- 'public': -- testing/taskcluster/tasks/decision/try.yml: artifacts: testing/taskcluster/tasks/decision/try.yml- 'public': -- testing/taskcluster/tasks/image.yml: artifacts: testing/taskcluster/tasks/image.yml- '{{artifact_path}}': -- testing/taskcluster/tasks/phone_build.yml: artifacts: testing/taskcluster/tasks/phone_build.yml- 'private/build': -- testing/taskcluster/tasks/test.yml: artifacts: testing/taskcluster/tasks/test.yml- 'public/logs/': -- testing/taskcluster/tasks/post-builds/mulet_simulator.yml: artifacts: testing/taskcluster/tasks/post-builds/mulet_simulator.yml- 'public/build': -- testing/taskcluster/tasks/builds/android_api_15_frontend.yml: artifacts: testing/taskcluster/tasks/builds/android_api_15_frontend.yml- 'public/android/unittest': -- testing/taskcluster/tasks/build.yml: artifacts: testing/taskcluster/tasks/build.yml- 'public/build': -- testing/taskcluster/tasks/tests/mulet_mochitests.yml.orig: artifacts: testing/taskcluster/tasks/tests/mulet_mochitests.yml.orig- 'public/build': -- testing/taskcluster/tasks/tests/fx_test_base.yml: artifacts: testing/taskcluster/tasks/tests/fx_test_base.yml- 'public/test': -- testing/taskcluster/tasks/tests/b2g_unittest_base.yml: artifacts: testing/taskcluster/tasks/tests/b2g_unittest_base.yml- 'public/build': and I talked with Callek a few days ago about h264 builds, and he will be putting those under project/releng.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Updated•5 years ago
|
Component: Documentation → Services
You need to log in
before you can comment on or make changes to this bug.
Description
•