Re: github quota limit when scanning with the addition of tags

[R. Tyler Croy]

(replies inline)

On Fri, 05 Jan 2018, Alicia Doblas wrote:

> Hi,
> 
> a couple of months ago we had the same problem. After improving the 
> discover filter of the branch/tag/PR calls, there weren't too much to 
> do...so we decided to "by-pass" the api of github by using different users. 
> Looks like the api limit applies to a single user, so the "solution" for us 
> was to split our jobs into different groups, each of them using a different 
> user for the api call. 
> 
> By changing this configuration we can manage 5000 req/hour x N groups.

This is very very much against the GitHub.com terms of service, which states
that one legal entity can have one free machine account.

https://help.github.com/articles/github-terms-of-service/#b-account-terms



- R. Tyler Croy

--
 Code: 
  Chatter: 
 xmpp: rty...@jabber.org

  % gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F
--

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/20180106042952.4wlg7enl4dbnnw5i%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: github quota limit when scanning with the addition of tags

[Alicia Doblas]

Hi,

a couple of months ago we had the same problem. After improving the 
discover filter of the branch/tag/PR calls, there weren't too much to 
do...so we decided to "by-pass" the api of github by using different users. 
Looks like the api limit applies to a single user, so the "solution" for us 
was to split our jobs into different groups, each of them using a different 
user for the api call. 

By changing this configuration we can manage 5000 req/hour x N groups.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/6a4743a2-f92d-40b0-beac-36fe30cfad1c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: secret token sent from gitlab webhook not being checked

[chris . every]

think I'll raise this on the gitlab-plugin github project, but if anyone 
here has any suggestions that'd be great. I'll post back here if I get any 
updates.

On Friday, 5 January 2018 10:47:10 UTC, chris...@paxport.net wrote:
>
> I'm trying to get the simple "secret token" auth working with multibranch 
> declarative pipelines on my gitlab webhooks.
>
> The webhooks (all "Push Hook") I've got set up seem to be working fine in 
> the sense that they fire the correct project; the URLs I've got defined in 
> the gitlab webhooks are of the format: /project/
>
> *It's the "secret token" part that's not being checked, regardless of what 
> I specify*. Checking the details of webhooks that have fired shows the 
> "X-Gitlab-Token" header being sent correctly.
>
>
> an example snippet from one of my declarative pipelines:
>
> options {
> gitLabConnection('gitlab')
> }
> triggers {
> gitlab(
> triggerOnPush: true,
> triggerOnMergeRequest: false, 
> triggerOpenMergeRequestOnPush: "never",
> triggerOnNoteRequest: false,
> noteRegex: "Jenkins please retry a build",
> skipWorkInProgressMergeRequest: false,
> ciSkip: false,
> setBuildDescription: false,
> addNoteOnMergeRequest: false,
> addCiMessage: false,
> addVoteOnMergeRequest: false,
> acceptMergeRequestOnSuccess: false,
> branchFilterType: "NameBasedFilter",
> includeBranchesSpec: "master",
> excludeBranchesSpec: "",
> secretToken: "_redacted_")
> }
>
> Once this pipeline has run for a project, I can see all the config 
> settings showing correctly in the "View Configuration" page of the 
> project/branch in Jenkins.
>
> So from what I can see, everything looks okay.
>
> I added a gitlab-plugin log recorder, and can see entries such as: 
>
>
> *"Jan 04, 2018 11:11:57 PM FINE 
> com.dabsquared.gitlabjenkins.webhook.build.PushBuildAction  Notify 
> scmSourceOwner  about changes for "*
> I'm not really au fait with the Jenkins codebase, but doing some quick 
> digging (and from log entries), suggests the project is an instance of 
> SCMSourceOwner, as opposed to an instance of Job. The former results in a 
> SCMSourceOwnerNotifier 
> which doesn't seem to use secretToken, whereas the latter results in a 
> TriggerNotifier which DOES use secretToken.
>
> So why are my projects instances of SCMSourceOwner, and to get the 
> secretToken functionality working, do I need to switch it to a Job, 
> somehow, or will I have some configuration incorrectly set, somewhere?
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/686fea78-9754-424d-b7dc-2c8d66323a52%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

secret token sent from gitlab webhook not being checked

[chris . every]

I'm trying to get the simple "secret token" auth working with multibranch 
declarative pipelines on my gitlab webhooks.

The webhooks (all "Push Hook") I've got set up seem to be working fine in 
the sense that they fire the correct project; the URLs I've got defined in 
the gitlab webhooks are of the format: /project/

*It's the "secret token" part that's not being checked, regardless of what 
I specify*. Checking the details of webhooks that have fired shows the 
"X-Gitlab-Token" header being sent correctly.


an example snippet from one of my declarative pipelines:

options {
gitLabConnection('gitlab')
}
triggers {
gitlab(
triggerOnPush: true,
triggerOnMergeRequest: false, 
triggerOpenMergeRequestOnPush: "never",
triggerOnNoteRequest: false,
noteRegex: "Jenkins please retry a build",
skipWorkInProgressMergeRequest: false,
ciSkip: false,
setBuildDescription: false,
addNoteOnMergeRequest: false,
addCiMessage: false,
addVoteOnMergeRequest: false,
acceptMergeRequestOnSuccess: false,
branchFilterType: "NameBasedFilter",
includeBranchesSpec: "master",
excludeBranchesSpec: "",
secretToken: "_redacted_")
}

Once this pipeline has run for a project, I can see all the config settings 
showing correctly in the "View Configuration" page of the project/branch in 
Jenkins.

So from what I can see, everything looks okay.

I added a gitlab-plugin log recorder, and can see entries such as: 


*"Jan 04, 2018 11:11:57 PM FINE 
com.dabsquared.gitlabjenkins.webhook.build.PushBuildAction  Notify 
scmSourceOwner  about changes for "*
I'm not really au fait with the Jenkins codebase, but doing some quick 
digging (and from log entries), suggests the project is an instance of 
SCMSourceOwner, as opposed to an instance of Job. The former results in a 
SCMSourceOwnerNotifier 
which doesn't seem to use secretToken, whereas the latter results in a 
TriggerNotifier which DOES use secretToken.

So why are my projects instances of SCMSourceOwner, and to get the 
secretToken functionality working, do I need to switch it to a Job, 
somehow, or will I have some configuration incorrectly set, somewhere?


-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/e5b26c5e-bbe0-4203-848b-053d11134ed0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.