The term on branch is a bit misleading here. It actually means if commit of the job can be reached from specified branch.

For your case, I guess head of master can also be reached from test branch.

I filed an improvement request #1635 to match build ref directly.

As to hide particular jobs from run menu, you may create necessary role without permission to run those jobs, and login as user with that role for your daily work.

@robin Thanks for your reply.

Then, what should I do if I want to only click Build job, and execute a branch-based job? Due to the above question, now we have to click Deploy (prod) on master branch, click Deploy (test) on test branch.Yes, both jobs have a job dependency to Build job.

And we maybe also use a Build Promotion, but in Builds section, the deployment process involves too many steps: choose a param named branch > choose a job to click.

Do you have suggestions about my case?

Oh, sorry. If I understand correctly, #1635 will be suitable for my case.

Then, what should I do if I want to only click Build job, and execute a branch-based job?

You may create only one deployment job, and configure it to behave differently based on value of variable @branch@

Then, what should I do if I want to only click Build job, and execute a branch-based job?

You may create only one deployment job, and configure it to behave differently based on value of variable @branch@

If so, I have to delete job secret Authorization, this is unacceptable for security.If I don't delete job secret Authorization and write a shell as follows:

if [ "@branch@" = "test" ] || [ "@branch@" = "dev" ];then
echo "deploy to test\n"
s="@secret:KUBECONFIG-test@"
elif [ "@branch@" = "master" ];then
echo "deploy to prod\n"
s="@secret:KUBECONFIG-prod@"
fi

this will lead to an error when running on test branch:

Job secret not authorized (project: xxxx, job secret: KUBECONFIG-prod)

this will lead to an error when running on test branch:

You may refer to #682 for a workaround.

To make such task easier, future version will improve job secrets so that multiple secrets with same name can be defined, and secret access will be tried one by one until an authorized secret can be found.

@lordran check this tutorial on how to use different job secret for different branchs in same job without resorting to groovy script:

https://docs.onedev.io/tutorials/cicd/branch-job-secret

@lordran check this tutorial on how to use different job secret for different branchs in same job without resorting to groovy script:

https://docs.onedev.io/tutorials/cicd/branch-job-secret

build #4343 is required to use this feature