I have a particular situation what I would like to share to make improvements or pull feedback.
We have several projects into same repository, and we would like to make the builds as granular as possible. I will try to summarize the problems in a compact example:
Our folder structure in github repository:
myRepository\
projectA\
projectB\
projectC\
Actual Continua CI Configuration
TriggerMaster:
Associate Changesets: Latest
Branch: master
Variables to True: %BuildProjectA%, %BuildProjectB%, %BuildProjectC%
TriggerA:
Branch: ^pr/.*
File Filters: projectA\\.*
Variables to True: %BuildProjectA%
TriggerB:
Branch: ^pr/.*
File Filters: projectB\\.*
Variables to True: %BuildProjectB%
TriggerC:
Branch: ^pr/.*
File Filters: projectC\\.*
Variables to True: %BuildProjectC%
Stage:
if (%BuildProjectA%) then
Action: Build Project A
if (%BuildProjectB%) then
Action: Build Project B
if (%BuildProjectC%) then
Action: Build Project C
Actual Behavior
User 1 creates PR #1:
Commit modified file in projectA\ folder
TriggerA fires
State Run Build #1 and generate \pr\1\ProjectA.exe
User 2 creates PR #2:
Commit modified files in projectB\ and projectC\ folders
TriggerB fires
State Run Build #2 and generate \pr\2\ProjectB.exe
TriggerC fires
State Run Build #3 and generate \pr\2\ProjectC.exe
User 3 modified some into master:
Commit modified file in projectA\ folder
TriggerMaster fires
State Run Build #4 and generate \master\ProjectA.exe, \master\ProjectB.exe, \master\ProjectC.exe
TriggerA fires (because PR #1 makes an auto merge from master)
State Run Build #5 and generate \pr\1\ProjectA.exe
TriggerB fires (because PR #2 makes an auto merge from master)
State Run Build #6 and generate \pr\2\ProjectB.exe
TriggerC fires (because PR #2 makes an auto merge from master)
State Run Build #7 and generate \pr\2\ProjectC.exe
Spected Behavior
User 1 creates PR #1:
Commit modified file in projectA\ folder
TriggerA fires
State Run Build #1 and generate \pr\1\ProjectA.exe
User 2 creates PR #2:
Commit modified files in projectB\ and projectC\ folders
TriggerB or just TriggerC fires
State Run Build #2 and generate \pr\2\ProjectB.exe, \pr\2\ProjectC.exe
User 3 modified some into master:
Commit modified file in projectA\ folder
TriggerMaster fires
State Run Build #3 and generate \master\ProjectA.exe, \master\ProjectB.exe, \master\ProjectC.exe
Improvements I Would Like to Get
PR #2 run the 2 projects into 1 build because the Github Status Event may be incorrect if just 1 project build fail;
Changes into master should not generate builds into PRs unless merge from the master in PRs are push by the owners;
There is a “Skip commits previously built for this configuration” checkbox on the Branch tab in the Trigger settings. This prevents more than one build running for the same commit.
If you tick this for each trigger, then this should result in the expected behaviour. However while testing this on your scenario today, we discovered due to a recent change in timing, that this does not always work. We are working on a fix for this and should have a new version available in the next couple of days.
Great that the option to skip previously built commits is working for you.
You can to use the new filtering tabs on User tab of repository trigger to, either exclude the GitHub user, so that the trigger doesn’t run when the pr is automatically merged, or supply a list of users to include, e.g. ^(dipold|jblogs)$$, so that the trigger only runs for commits by those users.
The git repository type doesn’t currently query any github specific information, so it doesn’t know whether a user is the repository owner, but hopefully this filtering handles your scenario?
Thanks. Apparently this setup solved almost all cases of unwanted builds.
I’m not sure if I understanding well the Associate Changesets where we have just a repository trigger. In the scenario described in my post, does this setting hinder my goal? What’s your advice?
The Associate Changesets option is primarily for display. It allows you to select which changesets are displayed on the Changes tab of the Builds view. e.g. /{ProjectName}/ci/builds/changes/{buildid}. It also defines which changesets are listed under the expression $Source.RepoName.Changesets$. It doesn’t affect which changeset is built.
If the “Latest” option is selected only the latest changeset on the current branch will be listed for each repository. If the “All since last successful build” option is selected then all changesets on the same branch since the last successful build will also be listed for each repository.
The operation of the “Skip commits previously built for this configuration” and “Skip commits previously built by this trigger” options could possibly be affected by this choice. When checking if a changeset has previously been built, Continua CI looks at all changesets which are associated with previous builds. If the “All since last successful build” option was selected when a previous build was triggered, earlier changesets on that branch would be included in this check. In the unlikely case that a new changeset is detected with the same revision and branch as one of these earlier changesets, perhaps due to a rebase, it would not get built. Generally, this would not be an issue.
I rushed over this solution. When a user creates a PR, the GitHub user makes an initial merge to creates the pr/[numberpr] branch, which makes it impossible exclude the GitHub user in the new Triggers User filtering.
What is making me sad (maybe this is a bug) is that sometimes when there are changes in the master, the triggers fire like I describe in Actual Behavior in my post:
But, the ProjectA.exe, ProjectB.exe and ProjectC.exe only contains the newly merged master changes, they doesn’t contains the changes of their respective PR #1 and PR #2.
If I select the build that generated ProjectA.exe, and click in Requeue Build, the same build generates the executable with the PR #1 changes correctly.
I am currently testing by unchecking all triggers the option “Skip commits previously built by this trigger”. If you have any suggestions on what I could do, I will be happy to try.
What have you got under Other Refs in your repository settings? By default this is: +refs/pull/*/merge:refs/remotes/origin/pr/*.
You can however change this to fetch the pull request heads e.g. +refs/pull/*/head:refs/remotes/origin/pr/*. Maybe this will work better for your scenario? See this old blog post: Building GitHub Pull Requests With Continua CI
Can you check the Changes tab for this build? Is the changeset listed with a green tick next to it as expected? Are the output folders external to the build workspace and therefore shared between builds? Is it possible that they are being overwritten by other builds running concurrently?
Can you check the Changes tab for the requeued build? Is the changeset listed with a green tick next to it the same changeset as the source build?
We have not been able to reproduce a situation where the wrong changeset is built. If you can reproduce this situation with debug logging enabled, and send the debug log to support @ finalbuilder.com or via a direct message on this forum, then we’ll look into what is causing this behaviour. Also let us know what the currently repository and trigger settings are at the time of the build - this information is included in the diagnostics report on the Admin - Event Log page so you can send this to save typing.
This checkbox can only be unchecked if “Skip commits previously built for this configuration” is also unchecked. You need to have “Skip commits previously built for this configuration” checked if you want to avoid separate triggers reacting to the same changeset.