Jenkins plugin that triggers builds on events that are published via Amazon Simple Queue Service (SQS) (Allow default IAM access (no access/security keys required).
Apache License 2.0
22
stars
35
forks
source link
Suggestion: Add message filtering for build triggers #19
The current design of the plugin seems to require a separate SQS queue for each project that you want to trigger independently. (ie: if you have two projects A & B, you need queueA, queueB if you want to have separate control of the builds).
With a small number of projects, this isn't bad. With a large number of projects, it requires a lot of queues, and queue configuration (at the jenkins level).
I propose adding a filtering option on the build trigger itself that matches the sos message body against some string (at least) to determine if the build should be triggered. (could be as basic as a simple String.contains() check)
This would enable using a single SQS queue to control multiple independent build triggers. From an administration standpoint this would reduce the amount of busy work required as you scale the number of projects your are building and also reduces the number of queues required to be created, configured, and maintained.
Continuing the previous example (assuming a simple String.contains() check), imagine three projects: A, B & C
Configure SQS queue: 'jenkins-build-queue'
A: add build trigger with 'jenkins-build-queue' and filter = 'project-a-build'
B: add build trigger with 'jenkins-build-queue' and filter = 'project-b-build'
C: add build trigger with 'jenkins-build-queue' and filter = '*' (let's call that filter the default)
Sending message 'project-a-build' to 'jenkins-build-queue': A&C builds, B does not
Sending message 'project-b-build' to 'jenkins-build-queue': B&C builds, A does not
Sending message 'foo' to 'jenkins-build-queue': C builds, A&B do not
The current design of the plugin seems to require a separate SQS queue for each project that you want to trigger independently. (ie: if you have two projects A & B, you need queueA, queueB if you want to have separate control of the builds).
With a small number of projects, this isn't bad. With a large number of projects, it requires a lot of queues, and queue configuration (at the jenkins level).
I propose adding a filtering option on the build trigger itself that matches the sos message body against some string (at least) to determine if the build should be triggered. (could be as basic as a simple String.contains() check)
This would enable using a single SQS queue to control multiple independent build triggers. From an administration standpoint this would reduce the amount of busy work required as you scale the number of projects your are building and also reduces the number of queues required to be created, configured, and maintained.
Continuing the previous example (assuming a simple String.contains() check), imagine three projects: A, B & C
Configure SQS queue: 'jenkins-build-queue' A: add build trigger with 'jenkins-build-queue' and filter = 'project-a-build' B: add build trigger with 'jenkins-build-queue' and filter = 'project-b-build' C: add build trigger with 'jenkins-build-queue' and filter = '*' (let's call that filter the default)
Sending message 'project-a-build' to 'jenkins-build-queue': A&C builds, B does not Sending message 'project-b-build' to 'jenkins-build-queue': B&C builds, A does not Sending message 'foo' to 'jenkins-build-queue': C builds, A&B do not