Instead of introducing a new workflow, I'd suggest to configure your CI job to use different job secret for pull request CI build and normal CI build on master branch:

To do it, please switch to menu Administration / Groovy Scripts to define a script with name say get-ci-secret-key with below content:

if (build.request != null)
    return build.getJobSecretAuthorizationContext().getSecretValue("ci_pull_request_key")
else
    return "ci_key" 

Then you can use @script:get-ci-secret-key@ to get value of desired secret. This way trusted code and untrusted code can use different environments for testing.

But then secrets may still be leaked by a malicious/tampered pull request... Even having separate secrets for CI and CD, one may still want to prevent CI (testing) secrets from being exposed, but still be able to use it on pull requests. Pull request build approval is something that's broadly adopted by CI/CD platforms. Here are some:

• GitLab
• Drone
• Jenkins
• Woodpecker (Fork of drone)
• Agola
• Concourse
• GoCD
• Circle CI

Secrets can be configured with authorized branches, which means only code reachable from these branches can use the secret. So it is not possible for malicious pull request to use protected secret, unless you merged the code, in which case means you've verified code to make sure it is safe.

As to pull request build approval, can you please guide me the detailed feature description in these products? I know that they have manual approval builds, but that can be achieved easily by manually running subsequent jobs in same OneDev pipeline.

Generally, when you set a project as "protected", it only run jobs if committer is the owner (or one of) of the project, other jobs wait for owner approvals, so secrets may be allowed in pull requests safely. When an contributor creates a PR, owners get notified that there are jobs waiting for their approval. This way, secrets may not need to be restricted to certain branches, as if an untrusted person creates a PR, jobs will not run, unless approved.

Like, if there is the need to use a secret for testing something and you don't want to expose it, there is no much choices without merging...