commit 242c3440784ca1adb86419548a3f2be7cfc2c3ce · hauleth.dev/blog

+5 -5

content/post/common-test-for-elixir.md

···

       103
       103
        
       

     

       104
       104
        
       Just check [this out](/common-test-example/simple/index.html). This is example report

     

       105
       105
        
       generated by the Common Test. As you can see it contains a lot of information in

     

       106
       106
       -
       quite readable format. Not only it contains informations about current run, but

     

       106
       106
       +
       quite readable format. Not only it contains information about current run, but

     

       107
       107
        
       all previous runs as well, which is really handy when tracking regressions.

     

       108
       108
        
       

     

       109
       109
       -
       But can we store even more informations there? Yes, as CT includes simple

     

       110
       110
       -
       logging facility it is completely possible to log your own informations during

     

       111
       111
       -
       tests, for example, lets modify our test to log some informations:

     

       109
       109
       +
       But can we store even more information there? Yes, as CT includes simple

     

       110
       110
       +
       logging facility it is completely possible to log your own information during

     

       111
       111
       +
       tests, for example, lets modify our test to log some information:

     

       112
       112
        
       

     

       113
       113
        
       ```erlang

     

       114
       114
        
       test_function_name(_Config) ->

     
···

       116
       116
        
           2 = 1 + 1.

     

       117
       117
        
       ```

     

       118
       118
        
       

     

       119
       119
       -
       Now when we run tests again, then we will see more informations (even coloured)

     

       119
       119
       +
       Now when we run tests again, then we will see more information (even coloured)

     

       120
       120
        
       in [our test log](/common-test-example/log/ct_run.ct@NiunioBook.2019-07-16_11.03.21/common-test-example.log.logs/run.2019-07-16_11.03.22/example_suite.test_function_name.html):

     

       121
       121
        
       

     

       122
       122
        
       ![Common Test log "Example message" on green background](/img/common-test/log.png)

+1 -1

content/post/log-all-the-things.md

···

       308
       308
        
       )

     

       309
       309
        
       ```

     

       310
       310
        
       

     

       311
       311
       -
       As we can see there, the report contains informations like:

     

       311
       311
       +
       As we can see there, the report contains information like:

     

       312
       312
        
       

     

       313
       313
        
       - `:label` - that describes type of the event

     

       314
       314
        
       - `:report` - content of the "main" event

+2 -2

content/post/who-watches-watchmen-i.md

···

       238
       238
        
       

     

       239
       239
        
       systemd supports the second approach via [`sd_notify`][sd_notify]. The approach

     

       240
       240
        
       there is simple - we have `NOTIFY_SOCKET` environment variable that contain path

     

       241
       241
       -
       to the Unix datagram socket, that we can use to send informations about state of

     

       241
       241
       +
       to the Unix datagram socket, that we can use to send information about state of

     

       242
       242
        
       our application. This socket accept set of different messages, but right now,

     

       243
       243
        
       for our purposes, we will focus only on few of them:

     

       244
       244
        
       

     

       245
       245
        
       - `READY=1` - marks our service as ready, aka it is ready to do its work (for

     

       246
       246
        
         example accept incoming HTTP connections in our example). It need to be sent

     

       247
       247
       -
         withing given timespan after start of the VM, otherwise the process will be

     

       247
       247
       +
         within given timespan after start of the VM, otherwise the process will be

     

       248
       248
        
         killed and possibly restarted

     

       249
       249
        
       - `STATUS=name` - sets status of our application that can be checked via

     

       250
       250
        
         `systemctl status hello.service`, this allows us to have better insight into