Home → Questions →

Why did one of these commit filters work and not the other?

• Edit

finnre

08 Aug, 2019 07:02 PM

I have a minimal(ish) repro this time, I swear! ;)

I got my original commit filter working in my test repo, giving me an extra job that only builds when you specify [full ci] in the commit message. To better match the state of the real repo I'm working on, I'm updating my test repo to have several extra jobs with a common variable that I can reference them by. I'll link the full config below but here's the relevant part as an illustration:

Previously:

environment:
  matrix:
  # ...
  - JOB_NAME: extra
    JOB_DESC: "the one that should only run by request"

# ...

-
  only_commits:
    message: /\[full ci\]/
  matrix:
    only:
      - JOB_NAME: extra

Updated:

environment:
  matrix:
  # ...
  - JOB_NAME: extra1
    JOB_DESC: "the first one that should only run by request"
    IS_EXTRA: true

  - JOB_NAME: extra2
    JOB_DESC: "the second one that should only run by request"
    IS_EXTRA: true

  # etc. (four total)

# ...

-
  only_commits:
    message: /\[full ci\]/
  matrix:
    only:
      - IS_EXTRA: true

This looks like the same logic to me; the matrix section of the only_commits filter is looking for a specific variable value, it's just looking for a different one. However, with the first configuration, the extra job successfully ran, and with the second configuration, none of the extra jobs ran.

I was wondering if maybe it's setting the variable as a boolean and testing it as a string, or vice versa, but quoting them explicitly doesn't help. Is there something unexpected about this filter behavior when the matrix section matches multiple jobs?

For the one that didn't work, the event log looks like this for each of the four extra jobs:

Job: "Environment: JOB_NAME=extra1, JOB_DESC=the first one that should only run by request, IS_EXTRA=true"
Documentation: https://www.appveyor.com/docs/branches/#white--and-blacklisting
Branches white-list:
  /^release.*/
Commit message: Readme update [full ci]
Webhook details:
  request URL: https://ci.appveyor.com/api/githubapp/webhook
  x-GitHub-Delivery: 5cc1e0f8-ba08-11e9-8479-486c2dd86c03
  x-GitHub-Event: push

(By the way, a couple of things that would've made my debugging life a little easier here: being able to navigate to older parts of the event log easily, and having more information in that log about events that successfully started. Would it be possible to see the conditions that matched, when that's applicable?)

1. 1 Posted by finnre on 09 Aug, 2019 12:04 AM

   

   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 [full ci] condition on master too though, let me see if I can find an example.

   • Edit

2. 2 Posted by finnre on 09 Aug, 2019 12:07 AM

   

   And this is why I take notes, heh. Here's the config file and result of a successful [full ci] run on master.

   ... and having found that, I can see that there's a second difference, which is that the extra 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 [full ci] work as expected on the master branch:

   for:
   -
     branches:
       only:
         - /^release.*/
     matrix:
       only:
         - JOB_NAME: release
         # - IS_EXTRA: 'true'
   

   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 matrix.only 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. :)

   • Edit

3. Support Staff 3 Posted by Owen McDonnell on 09 Aug, 2019 07:30 AM

   

   Sorry for the delay.
   From what i see, it is still the tag filtering that is causing unexpected build behaviours ... Therefore, please read my response in the other thread and then we can continue trying to clarify here.

   • Edit

4. 4 Posted by finnre on 09 Aug, 2019 07:18 PM

   

   Saw that, thank you. I think this case is pretty different because I'm not looking at tags at all here (yet), just the [full ci] 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 /^release.*/ affect the behavior on master? Or, alternatively: how exactly is Appveyor turning these configs into decisions?

   • Edit

5. Support Staff 5 Posted by Owen McDonnell on 10 Aug, 2019 05:42 PM

   

   In the config of the last example you mentioned i don't see anything surprising.

   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 "release" any branch other than release should not run. In the second block you say, for the matrix job called "nightly" any branch other than nightly should not run (which in this case precludes that job). Finally, in the last block you say for the matrix job called "extra", it should only be run if the commit includes [full ci].

   Note that if you have another config block that made another condition on "nightly" job, or added it to the matrix.only construct of the second (nightly) block, that would be irrelevant since the job has already been dismissed.

   I'm not sure that answers you final question, except to say that changing what's enabled for release branches doesn't affect behaviour on master unless there is a matrix job that has contradicting conditions.

   It might promote more understanding, should you continue to experiment, to switch your config blocks to placing the matrix.only node first, since, at least in my way of looking at it, that is the starting point.

   • Edit

6. 6 Posted by finnre on 12 Aug, 2019 06:59 PM

   

   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 test and release 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.

   The rest is mostly about whether branches.only ... matrix.only 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 matrix.only nodes first in that case -- being able to specify those in either order is definitely not helping, heh.

   I'll take another stab at it with that in mind. Thanks.

   • Edit

7. 7 Posted by finnre on 13 Aug, 2019 11:18 PM

   

   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. :)

   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.

   • Edit

8. Support Staff 8 Posted by Owen McDonnell on 14 Aug, 2019 03:40 AM

   

   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).
   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.

   • Edit

9. Owen McDonnell closed this discussion on 14 Aug, 2019 03:40 AM.