Add all trigger fields to the documentation

[mtalexan]

Describe your use-case which is not covered by existing documentation.

The current documentation lists only a subset of the fields that are available for scripted and declarative syntax gitLab triggers. Reading the code itself is necessary to determine what options are actually available.

Currently documented scripted:

branchFilterType: 'All',
triggerOnPush: true,
triggerOnMergeRequest: false,
triggerOpenMergeRequestOnPush: "never",
triggerOnNoteRequest: true,
noteRegex: "Jenkins please retry a build",
skipWorkInProgressMergeRequest: true,
secretToken: project_token,
ciSkip: false,
setBuildDescription: true,
addNoteOnMergeRequest: true,
addCiMessage: true,
addVoteOnMergeRequest: true,
acceptMergeRequestOnSuccess: false,
branchFilterType: "NameBasedFilter",
includeBranchesSpec: "release/qat",
excludeBranchesSpec: "",

Available, but missing from this list:

triggerOnBranchDeleteRequest: true,
triggerOnlyIfNewCommitsPushed: false,
triggerOnPipelineEvent: false,
triggerOnAcceptedMergeRequest: true,
triggerOnClosedMergeRequest: false,
triggerOnApprovedMergeRequest: false,
labelsThatForcesBuildIfAdded: "",
branchFilterName: "",
sourceBranchRegex: "",
targetBranchRegex: '^(.*/)?main$',
mergeRequestLabelFilterConfig: [
    include: "",
    exclude: ""],
pendingBuildName: "jenkins",
cancelPendingBuildsOnUpdate: true

Currently documented Declarative:

triggerOnPush: false,
triggerOnMergeRequest: true, 
triggerOpenMergeRequestOnPush: "never",
triggerOnNoteRequest: true,
noteRegex: "Jenkins please retry a build",
skipWorkInProgressMergeRequest: true,
ciSkip: false,
setBuildDescription: true,
addNoteOnMergeRequest: true,
addCiMessage: true,
addVoteOnMergeRequest: true,
acceptMergeRequestOnSuccess: false,
branchFilterType: "NameBasedFilter",
includeBranchesSpec: "release/qat",
excludeBranchesSpec: "",
pendingBuildName: "Jenkins",
cancelPendingBuildsOnUpdate: false,
secretToken: "abcdefghijklmnopqrstuvwxyz0123456789ABCDEF"

Available, but missing from this list:

triggerToBranchDeleteRequest: false,
triggerOnlyIfNewCommitsPushed: false,
triggerOnPipelineEvent: false,
triggerOnAcceptedMergeRequest: true,
triggerOnClosedMergeRequest: false,
triggerOnApprovedMergeRequest: false,
labelsThatForcesBuildIfAdded: "",
branchFilterName: "",
sourceBranchRegex: "",
targetBranchRegex: '^(.*/)?main$',
mergeRequestLabelFilterConfig: [
    include: "",
    exclude: ""],

These are probably non-exhaustive lists, but they're what I was able to somewhat easily find when digging thru the code.

Might be good intro task for GSoC to familiarize with the structure, as loosely discussed #1005

Reference any relevant documentation, other materials or issues/pull requests that can be used for inspiration.

No response

[AniketNS]

Hey @mtalexan, I'd like to solve this problem. Can you please assign this to me?

[MarkEWaite]

Hey @mtalexan, I'd like to solve this problem. Can you please assign this to me?

@AniketNS we don't assign issues to individuals that are not maintainers of the plugin. Your comment that you're interested in working on this issue is enough that others will ask about it before they start any work on the issue.

When we have assigned issues to non-maintainers in the past, the issue stopped progressing and other non-maintainers were unwilling to work on the issue, even long after the new assignee had stopped all work on it.

[AniketNS]

That won't happen in my case. I'll solve the issue completely.

[briantist]

@AniketNS why do you need the issue assigned? Open the PR if you're able to solve it.

I do the same as they do on projects I maintain: assign only maintainers as assignee. It does not stop anyone from contributing.

[AniketNS]

Ohh that's what you meant. Sure then I'll do that.

[MarkEWaite]

Ohh that's what you meant. Sure then I'll do that.

That's great. Pull requests are welcomed. We don't want the overhead of assigning an issue to a non-maintainer and then needing to decide at some point in the future if the non-maintainer has not started their work, paused their work, or stopped their work.

[AniketNS]

Yeah, that's right. It's a good point. Actually, from here now on I won't ask anyone to assign me an issue. First I'll make the PR and then I'll ask them for review or about assigning me an issue.

[AniketNS]

But in this way, I won't be able to ask for help from maintainers. What would you suggest to me to solve this problem?

[MarkEWaite]

But in this way, I won't be able to ask for help from maintainers. What would you suggest to me to solve this problem?

Why do you think that you won't be able to ask for help from maintainers? Maintainers will see the pull request and can ask questions in the pull request. A pull request is a better place to ask a question because it shows where you've started and shows that you're doing some work yourself before asking a question.

It is a common pattern that new contributors ask "how do I do that?" without doing enough of their own work to attempt to solve the problem. After asking that type of question, then the new contributor expects a maintainer to guide them through every step of the change. That type of interaction wastes the time of the maintainer and slows the learning of the new contributor.

[AniketNS]

Yeah, gotcha. Learn something new from you. I'll approach this way from now on. Thanks for this perspective.

[AniketNS]

Hey @MarkEWaite I've opened the PR. Please check and tell me if I've made the correct changes or not.

[krisstern]

Hi @AniketNS The PR has already been accepted and merged

[AniketNS]

Yeah, Thanks