Project-specific variables

[audibleblink]

Something like key-value pairs that are stuck to Operations would be useful.

This would allow for people with custom Workers to make decisions based on a projects' variables.

An example: Slack channel names

1. create new project called '2023-Q1-example.com'

• do normal setup like users, tags, groups, etc
• create project variables
  • slack_channel: example.com_campaign
  • slack_webhook: https://.........

2. Create new evidence
3. A Worker can now query an operation's slack_channel variable and post to that slack channel that evidence was created

Currently I'm using a dictionary in source to map operation slugs to slack-channel slugs. On every new operation, I'm going in to the source to add a new entry and then rebuilding/publishing new docker images. I then pull the image on a docker swarm manager and redeploy the slack worker.
I was about to start the process of modifying my worker to be able to read in and build that dictionary from environment variables, when the idea of operation variables popped in to my head.

[jrozner]

A few clarifying questions.

1. Would you want global ones for the instance as well?
2. If so, would you want project specific ones to override the global ones?
3. How would you want the worker to get access to this data?

[audibleblink]

1. Yes, that could be useful for setting base urls to external services, as an example.
2. Yes, I think that's sound default behavior for configuration variables
3. I don't have strong feelings about whether the variables are pushed to workers, or if workers have to fetch them with an API call.

It's probably cleaner to make them available to read rather than pushing the same variables over and over.

[jkennedyvz]

1. This is a good idea
2. Yes
3. Having the server pass global and project variables along with the evidence should help minimize overhead from requests and serialization.

[jkennedyvz]

This should be closed with the 2023.3 release