The parameter-function is used to add more build parameters just before a job is launched in Gearman. The related code is:

def updateBuildParams(self, job, item, params):
    """Allow the job to modify and add build parameters"""

    # NOTE(jhesketh): The params need to stay in a key=value data pair
    # as workers cannot necessarily handle lists.

    if callable(job.parameter_function):
        pargs = inspect.getargspec(job.parameter_function)
        if len(pargs.args) == 2:
            job.parameter_function(item, params)
        else:
            job.parameter_function(item, job, params)
        self.log.debug("Custom parameter function used for job %s, "
                       "change: %s, params: %s" % (job, item.change,
                                                   params))

Which lets one extend the list of ZUUL_* parameters that are injected by Zuul itself. parameter-function acts when a job is launched.

The &email_allowlist is a pointer to a list of email regex that is then reused to filter events that trigger a Zuul pipeline. It is a way to determine whether a given event is accepted in the pipeline, that is done even before the project is looked up or the jobs to launch is determined. Or in short, it is for a different purpose and can't rely on the parameter function.

To remove the crazy allow list, we could have Zuul to query Gerrit to check whether a user is in the trusted users group, but there is no such logic for it and I don't want to add and maintain any code to our legacy Zuul v2.5.

Right. :-(

We could have a script that reformats and dumps our pretty trusted-users.yaml into zuul/layout.yaml. That might be more work though.

In T279594#6984861, @Legoktm wrote:

We could have a script that reformats and dumps our pretty trusted-users.yaml into zuul/layout.yaml. That might be more work though.

As part of the CI process? That could work.