tag:help.appveyor.com,2012-11-13:/discussions/questions/40351-why-did-one-of-these-commit-filters-work-and-not-the-otherAppVeyor: Discussion 2019-08-14T03:40:48Ztag:help.appveyor.com,2012-11-13:Comment/475118002019-08-09T00:04:20Z2019-08-09T00:04:20ZWhy did one of these commit filters work and not the other?<div><p>I just noticed that's not a good comparison -- the version that worked was on a release branch in that case. I have successfully tested the <code>[full ci]</code> condition on master too though, let me see if I can find an example.</p></div>finnretag:help.appveyor.com,2012-11-13:Comment/475118002019-08-09T00:07:31Z2019-08-09T00:54:44ZWhy did one of these commit filters work and not the other?<div><p>And this is why I take notes, heh. Here's the <a href="https://github.com/relsqui/matrix-repro/blob/9301c455b406502708e813e37377b067440bdde1/appveyor.yml">config file</a> and <a href="https://github.com/relsqui/matrix-repro/blob/9301c455b406502708e813e37377b067440bdde1/appveyor.yml">result</a> of a successful <code>[full ci]</code> run on master.</p>
<p>... and having found that, I can see that there's a second difference, which is that the <code>extra</code> job(s) weren't enabled on release branches before (that's a change I made in the interim). Indeed, commenting that out in the new config makes <code>[full ci]</code> work as expected on the master branch:</p>
<pre>
<code>for:
-
branches:
only:
- /^release.*/
matrix:
only:
- JOB_NAME: release
# - IS_EXTRA: 'true'</code>
</pre>
<p>This means I'm still not totally getting how these selectors work, heh. I'm thinking of it as "under these conditions, run these specific jobs," but this implies that the <code>matrix.only</code> construct is exclusive between different commit filtering blocks. I think I can get around it in the immediate case by using two different variables for these cases (and just putting both in the matrix entry for the extra jobs), but I'd like to understand better how these filters are processed so I stop getting surprised by this stuff. I promise if I actually manage to wrap my head around it well enough to pass it on, I'll make you a docs PR. :)</p></div>finnretag:help.appveyor.com,2012-11-13:Comment/475118002019-08-09T07:30:15Z2019-08-09T07:30:15ZWhy did one of these commit filters work and not the other?<div><p>Sorry for the delay.<br>
From what i see, it is still the tag filtering that is causing unexpected build behaviours ... Therefore, please read my response in <a href="https://help.appveyor.com/discussions/questions/39782-job-specific-commit-filtering">the other thread</a> and then we can continue trying to clarify here.</p></div>Owen McDonnelltag:help.appveyor.com,2012-11-13:Comment/475118002019-08-09T19:18:32Z2019-08-09T19:18:32ZWhy did one of these commit filters work and not the other?<div><p>Saw that, thank you. I think this case is pretty different because I'm not looking at tags at all here (yet), just the <code>[full ci]</code> commit flag (and the actual branch name). I guess I can distill my question here to: Why does changing what's enabled for branches that match <code>/^release.*/</code> affect the behavior on <code>master</code>? Or, alternatively: how exactly is Appveyor turning these configs into decisions?</p></div>finnretag:help.appveyor.com,2012-11-13:Comment/475118002019-08-10T17:42:47Z2019-08-10T17:42:47ZWhy did one of these commit filters work and not the other?<div><p>In the config of the <a href="https://ci.appveyor.com/project/relsqui/matrix-repro/builds/26485144">last example</a> you mentioned i don't see anything surprising.</p>
<p>I'll try to put it prosaically. You define a 4 job matrix, then in the first conditional block you state, for the matrix job called "<em>release</em>" any branch other than <em>release</em> should not run. In the second block you say, for the matrix job called "<em>nightly</em>" any branch other than <em>nightly</em> should not run (which in this case precludes that job). Finally, in the last block you say for the matrix job called "<em>extra</em>", it should only be run if the commit includes <code>[full ci]</code>.</p>
<p>Note that if you have another config block that made another condition on "<em>nightly</em>" job, or added it to the <code>matrix.only</code> construct of the second (<em>nightly</em>) block, that would be irrelevant since the job has already been dismissed.</p>
<p>I'm not sure that answers you final question, except to say that changing what's enabled for <em>release</em> branches doesn't affect behaviour on master unless there is a matrix job that has contradicting conditions.</p>
<p>It might promote more understanding, should you continue to experiment, to switch your config blocks to placing the <code>matrix.only</code> node first, since, at least in my way of looking at it, that is the starting point.</p></div>Owen McDonnelltag:help.appveyor.com,2012-11-13:Comment/475118002019-08-12T18:59:57Z2019-08-12T18:59:57ZWhy did one of these commit filters work and not the other?<div><p>Ahh, that's definitely one thing I was missing -- it actually didn't even occur to me that the order of these blocks mattered. I was thinking of it like the job definition in the matrix, where switching the order of the <code>test</code> and <code>release</code> jobs (or whatever) wouldn't do anything because it's just defining a set. Approaching it as a series of instructions (like the script steps) does resolve some of my confusion.</p>
<p>The rest is mostly about whether <code>branches.only ... matrix.only</code> means "for these branches, run only these jobs" or "for these jobs, run only on these branches." I had inferred the first from earlier experiments, and you seem to be saying the second. I definitely agree with putting the <code>matrix.only</code> nodes first in that case -- being able to specify those in either order is definitely not helping, heh.</p>
<p>I'll take another stab at it with that in mind. Thanks.</p></div>finnretag:help.appveyor.com,2012-11-13:Comment/475118002019-08-13T23:18:48Z2019-08-13T23:18:48ZWhy did one of these commit filters work and not the other?<div><p>That actually turned out to be pretty simple; since I want to have multiple conditions to include a job, I think I can't use the commit filter mechanism at all. I just have to start the jobs, check for multiple conditions manually, and then bail out early with Exit-Appveyor if they aren't met. That at least is pretty straightforward to implement. :)</p>
<p>I think this is wrapped up for now. Thanks again for all your help, I really appreciate it. I might still take a crack at a small docs PR if I can come up with words that would've helped me figure this out faster, and if you'd like that.</p></div>finnretag:help.appveyor.com,2012-11-13:Comment/475118002019-08-14T03:40:47Z2019-08-14T03:40:47ZWhy did one of these commit filters work and not the other?<div><p>Thanks for your patience. Its good for us support people to deal with some more advanced use cases from time to time (even though we don't always come up with solutions/reasons super quickly).<br>
We'd be happy to receive a docs PR if you, as you say, find the words. I know this can be a confusing area for people using AppVeyor and the docs could definitely be better.</p></div>Owen McDonnell