Advice on handling secrets in hosted Sanity studio and triggering GitLab pipeline.

I am looking for some advice on how to handle secrets in a hosted sanity studio. I want to be able to trigger a GitLab pipeline in some way, currently investigating Document Actions, so that we can re-build a static site that has it's content hosted in Sanity. I was considering using environment variables to store the GitLab trigger token, but the documentation says not to put secrets in there. What is the recommended approach for this sort of thing? I am starting to look at plugins to see if they are a better fit for what we need.

Thank you for your reply. I initially looked at adding a webhook, but the GitLab pipeline trigger needs to have a secure token included in the POST to the API endpoint, which I believe is not possible with the webhook approach.I believe that the intention is to upgrade to an Advanced plan once we have proven that we can work with Sanity in the way that we need, so I guess the Custom Access Controls will be out of scope for our potential solution.
I will keep looking into the plugin approach, as things like the sanity => netlify plugin appear to store secrets in their configuration, so I just need to understand how secure that is.

Thank you for your reply. I initially looked at adding a webhook, but the GitLab pipeline trigger needs to have a secure token included in the POST to the API endpoint, which I believe is not possible with the webhook approach.I believe that the intention is to upgrade to an Advanced plan once we have proven that we can work with Sanity in the way that we need, so I guess the Custom Access Controls will be out of scope for our potential solution.
I will keep looking into the plugin approach, as things like the sanity => netlify plugin appear to store secrets in their configuration, so I just need to understand how secure that is.

As a follow up question, do you have any ideas if the outbound calls made by the webhooks come from specific IPs or IP ranges? Just trying to work out how we might secure a lambda function so that it isn't completely public, but allow a webhook to invoke it

Unfortunately due to the cloud architecture, it's all coming from random IPs, so there's probably not a consistent way of checking against that.
Thinking a bit more about the plugin i posted above. You could potentially create a second dataset for your project to house your secrets and make that entire dataset private. At that point, you'd need to make an authenticated API call to the private dataset to get and transmit your secret to GitLab during the script you run for the Custom Document Action you mentioned