Mark: Thank you for the idea. While I think that would work for now, I'm concerned about needing to statically specify so much of what is already provided by the built-in `scm` global variable. (As Christian also raises in JENKINS-37817.)

Christian: Thank you for that explanation. Makes sense. Based on your explanation, it sounds like being able to specify 'clean before checkout' in the org plugin wouldn't accomplish what I want anyway. (Since I think i'd be cleaning the `<branch>@script` working copy rather than the actual workspace where the build it going to happen? If I've got that right, then I think this issue is probably invalid.

Right. There are two issues, really...

1. The <branch>@script checkout on the master should probably always use shallow to prevent huge checkout times. If there was another way to just get the correct Jenkinsfile (e.g. https://raw.<github-url>/<org>/<repo>/<branch-or-ref>/Jenkinsfile?token=<token>) that'd be even better.
2. The checkout scm needs to be configurable so changes specific to a repository can be setup, such as setting "clean before checkout" or "shallow clone". Otherwise this cannot be setup due to the way the GitHub Org Folder works.

The second item is what I'm concerned about here. I should file another issue on the first item.

I created JENKINS-38212 to address the "getting the Jenkinsfile" story.

closing because i believe that allowing additional git operations via Github Organization configuration will not have the effect I want to achieve. i want to remove old artifacts from a workspace prior to a build, but i believe that running `git clean` & etc during the initial checkout would actually clean the `project@script` working copy instead.

if a maintainer thinks i've summarized this incorrectly, please re-open.

markewaite I tried your Jenkinsfile against our Git Hub Enterprise and it failed because it doesn't have the correct credentials. I could shoe-horn them in there someplace (not sure where, since this interface is confusing).

Either way, having to write that massive amount of boiler plate when all the values are in the scm object right now is really bad UX design.

alexdean It isn't clear what added the web-ui options would do. It would probably do both the <branch>@script and the checkout scm. Which would be better than nothing, but not allow the per-repository control that people really need.

docwhat when you say that people need "per-repository control", do you mean that they want a setting which controls all repositories within the entire organization (in my case, that would be "git-plugin", "git-client-plugin", and "jenkins-bugs"), or would it be a setting per repository (one each for "git-plugin", "git-client-plugin", and "jenkins-bugs"), or would it be a setting per branch ("git-plugin:master", "git-plugin:3.0.0-beta", etc.)?

I assumed from the phrase "per-repository" that you meant one for each repository in the organization. If that is the case, then doesn't that mean that the definition needs to be associated to each repository? I'm not sure how we would associate the definition to a repository, since currently the Jenkinsfile is per branch. I guess we could declare that the "per-repository" control is the Jenkinsfile which comes from the master branch, though the git purists will likely complain that master is just a convention, not a mandate.

By "per repository" I guess I really meant "per branch". Specifically, control it via a Jenkinsfile. Ideally by modifying the scm object or creating a copy in a simple way (not by copying every element one by one).

Some examples that I have been recently asked about:

• Shallow clones
• Altering timeouts
• Clean before/after checkouts
• Calculate Changelog against specific branch
• etc.

Those can all be set through the checkout() step. They may also be accessible from the scm object. I've not experimented with trying to use them from the scm object. If I find a way to read the existing value from the scm object so that it can be reused in the checkout() step, I'll certainly post it here.

They cannot be read without triggering the need for a lot of accept approvals. See the linked issue: JENKINS-37817 for the list the last time I tried. That list grew as of yesterday's versions of things.