• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

cloudmarker / cloudmarker / 845 / 3
84%
master: 84%

Build:
DEFAULT BRANCH: master
Ran 17 May 2019 03:03PM UTC
Files 39
Run time 2s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

16 May 2019 12:04PM UTC coverage: 90.823% (-0.3%) from 91.16%
845.3

push

travis-ci-com

susam
Check only vm_instance_view data in disk plugins

The current implementations of `AzVMOSDiskEncryptionEvent` and
`AzVMDataDiskEncryptionEvent` plugins generate events for VM records
obtained by `AzCloud` as well. This is a problem when both `AzCloud` and
`AzVM` belong to the same audit definition. Here is an example minimal
config that reproduces this issue:

    plugins:
      myazcloud:
        plugin: cloudmarker.clouds.azcloud.AzCloud
        params:
          tenant:
          client:
          secret:

      myazvm:
        plugin: cloudmarker.clouds.azvm.AzVM
        params:
          tenant:
          client:
          secret:

    audits:
      myazaudit:
        clouds:
          - myazcloud
          - myazvm
        stores:
          - filestore
        events:
          - firewallruleevent
          - azvmosdiskencryptionevent
          - azvmdatadiskencryptionevent
        alerts:
          - filestore
    run:
      - myazaudit

Assuming there is only one VM in the cloud, `AzVMOSDiskEncryptionEvent`
would generate two events, one for the `virtual_machine` record
generated by `AzCloud` and one more for the `vm_instance_view` record
generated by `AzVM`.

Since these two plugins work only on `vm_instance_view` records (i.e.,
extended record type is `vm_instance_view`), it should ignore any other
extended record types. This change implements this.

Further, while implementing this change, I realized that it would be
better to not log warning messages for missing `com` and `ext` buckets.
One of the design goals of this project has been to let users write
their own plugins in which they are free to choose their record format.
If their records do not have `com` and `ext` buckets but these plugins
are configured to receive them, then these plugins should silently
ignore any records that these plugins do not care about instead of
logging a warning message for every record that does not meet these
plugins' expected format.

430 of 481 branches covered (89.4%)

Branch coverage included in aggregate %.

1866 of 2047 relevant lines covered (91.16%)

0.91 hits per line

Source Files on job 845.3
  • Tree
  • List 0
  • Changed 4
  • Source Changed 4
  • Coverage Changed 2
Coverage ∆ File Lines Relevant Covered Missed Hits/Line Branch Hits Branch Misses
  • Back to Build 683
  • Travis Job 845.3
  • f0a721b6 on github
  • Prev Job for on master (#840.2)
  • Next Job for on master (#855.2)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc