Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build PR every time AFTER comment #6

Closed
MichalPloski opened this issue Oct 18, 2018 · 1 comment
Closed

Build PR every time AFTER comment #6

MichalPloski opened this issue Oct 18, 2018 · 1 comment

Comments

@MichalPloski
Copy link

Currently we have two options to modify plugin behaviour:
a) Trigger build after specific comment
b) Trugger build after PR is updated

I would like to have option to merge those two options in a following way:
a) User comment Pull Request and Build is triggered. Then this PR is marked
b) Marked PR is then updated automatically every time commit is done

This differ from b) in a way that not every PR is updated but those ones that are previously marked by user - this allows us to remove unnecessary load as we don't want to build all active PRs

@bluesliverx
Copy link
Contributor

You probably could do this with pipeline scripts as it is today if you setup a build to build after any comment (.*) and then change the configuration through the properties call (not sure what this looks like in declarative pipeline since we don't use it). Alternatively, if you have a global pipeline library set up, you could use it to add an additional Action to the raw build itself, and then check for that action on subsequent builds to see if anything needs to be done.

In our usage of our, we actually use two different multibranch pipeline jobs for each module in our system. The first multibranch job takes care of the heavy lifting of the build itself, and is only triggered from commit changes or a very specific message like "REBUILD". The second multibranch job runs a very quick, very small job on every PR comment that does some other things for us. You could use a similar setup to prevent comments from causing too many builds.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants