1449508 - scriptworker: Define standard names for scopes?

Status: RESOLVED FIXED

(Release Engineering :: Release Automation, enhancement)

Description

[Johan Lorenzo [:jlorenzo]]

Conversation started at [1]. Aki and I are on the fence about how we should name scopes like:
>  project:releng:{external_service}:{variable_of_that_service}

For instance:
> project:releng:beetmover:bucket:nightly
> project:releng:signing:cert:release-signing
> project:releng:snapcraft:firefox:candidate


We have 2 proposals:

1. {variable_of_that_service} should be the raw value consumed by *script. For instance beetmover script knows it has to talk to the bucket called "nightly", or pushsnapscript knows it should push the candidate channel.
Pro: Debugging scopes of a bogus task is immediate, if you know what the task does.
Con: `scriptworker/constants.py` is full of custom values that have nothing to do from one service to another.

2. {variable_of_that_service} should be standard across scriptworker types. For example, we use project:releng:signing:cert:release or project:releng:snapcraft:firefox:release. Thus, *script has to map this value to the value expected by the service. E.g.: project:releng:snapcraft:firefox:release is extracted as "release" but mapped as "candidate"; this way the snap is still pushed to the candidate channel.
Pro: All tasks have similar scopes; a newcomer doesn't have to know what the task does to understand what type of environment it interacts.
Cons: This adds a layer of indirection. One has to looks at the logs to ensure the right value is passed to the service. Another issue is: We may have overlapping confusing values. For instance, in the Snap world the "release" channel does exist[2]. Mapping the "release" scope to the "candidate" channel can confuse somebody who's familiar with what the task does.


What do you all think? I NI'd people who I remember worked with *script implementations. Feel free to add anybody I may have missed. 



[1] https://github.com/mozilla-releng/scriptworker/pull/198#discussion_r177162065
[2] https://docs.snapcraft.io/reference/channels#risk-levels-meaning

Comment 1

[[e-mail] (:bhearsum)]

I'm not plugged into this enough to be able to offer a useful opinion past "consistency is good!".

Comment 2

[Simon Fraser [:sfraser] ⌚️GMT]

(In reply to Johan Lorenzo [:jlorenzo] from comment #0)
 
> 
> 2. {variable_of_that_service} should be standard across scriptworker types.

> Pro: All tasks have similar scopes; 

I'm not sure that's a Pro if the scopes don't describe what the scope is used for without a mapping table. I think that's my primary concern: Does the name of the scope give a clear description?

Comment 3

[Aki Sasaki (not active)]

Currently leaning towards descriptive names, and adding a scopes.md to every *script repo.

- we're going to have scope differences anyway, e.g. :cert: vs :bucket: vs :channel:
- signing may have release, nightly, and dep signing on the same branch, depending on what we're signing (fx release shippable vs devedition shippable vs dep builds)

The scopes.md would contain the following info:

- scope patterns
- whether the scopes are restricted or not. f/e, signing :format: is unrestricted, merely informative. the :cert: is restricted, though dep-signing is open
- what branches / products we expect to see these used on

Comment 4

[Aki Sasaki (not active)]

(The scopes.md in the root of each *script repo gives us a standard place to look for these.)

Comment 5

[Johan Lorenzo [:jlorenzo]]

scopes.md and non-standard names sounds sane to me!

Comment 6

[Mihai Tabara [:mtabara]⌚️GMT]

(In reply to Aki Sasaki [:aki] from comment #4)
> (The scopes.md in the root of each *script repo gives us a standard place to
> look for these.)

This sounds like a good approach to me, neat!
Sorry for delays.

Comment 7

[Tom Prince [:tomprince]]

:+1: For descriptive names.

This means that we can do things like land experiments that push to staging to mozilla-central or comm-central with less confusion. Instead of the scope and project being from the same set of things but different values, they will just be from different sets of things.

Comment 8

[Johan Lorenzo [:jlorenzo]]

We now have a consensus on descriptive names. Thank you all for your input!