lb-nightly-functions issueshttps://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/issues2022-04-28T15:59:26+02:00https://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/issues/21change the timestamp field name for opensearch entries to `@timestamp`2022-04-28T15:59:26+02:00Marco Clemencicmarco.clemencic@cern.chchange the timestamp field name for opensearch entries to `@timestamp`I'm not an expert, but [fluent-bit](https://fluentbit.io/) and [opensearch docs](https://opensearch.ossez.com/dashboards/dql/#date-and-range-queries) use `@timestamp` for the timestamp field of records, instead of `timestamp` as we do.I'm not an expert, but [fluent-bit](https://fluentbit.io/) and [opensearch docs](https://opensearch.ossez.com/dashboards/dql/#date-and-range-queries) use `@timestamp` for the timestamp field of records, instead of `timestamp` as we do.Maciej Pawel SzymanskiMaciej Pawel Szymanskihttps://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/issues/20Fix issue with getting kerberos credentials2022-02-08T16:16:55+01:00Maciej Pawel SzymanskiFix issue with getting kerberos credentialsAfter https://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/merge_requests/80, we get kerbersos credentials using keytab. We happen to call `kinit` taken from `conda` environment (`krb5` is one of indirect dependency). H...After https://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/merge_requests/80, we get kerbersos credentials using keytab. We happen to call `kinit` taken from `conda` environment (`krb5` is one of indirect dependency). However, this breaks system kerberos configuration, possibly related with https://github.com/ContinuumIO/anaconda-issues/issues/10772. The issue goes away using `kinit` from `/cvmfs/.../LbEnv/...` or the system one:
```bash
-bash-4.2$ sudo -u lblocal /home/lblocal/override_envs/functions/bin/kinit -k -t /home/lblocal/private/lhcbsoft.keytab lhcbsoft@CERN.CH
kinit: Pre-authentication failed: Invalid argument while getting initial credentials
-bash-4.2$ sudo -u lblocal /cvmfs/lhcb.cern.ch/lib/var/lib/LbEnv/2314/stable/linux-64/bin/kinit -k -t /home/lblocal/private/lhcbsoft.keytab lhcbsoft@CERN.CH
-bash-4.2$
-bash-4.2$ sudo -u lblocal /usr/bin/kinit -k -t /home/lblocal/private/lhcbsoft.keytab lhcbsoft@CERN.CH
-bash-4.2$
```https://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/issues/19`mock.called_once_with` does not assert2021-12-17T10:23:22+01:00Rosen Matev`mock.called_once_with` does not asserta few tests call `.called_once_with()` instead of `.assert_called_once_with()`. This creates a mock instead of asserting, see https://docs.python.org/dev/library/unittest.mock.html#autospeccinga few tests call `.called_once_with()` instead of `.assert_called_once_with()`. This creates a mock instead of asserting, see https://docs.python.org/dev/library/unittest.mock.html#autospeccinghttps://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/issues/18The mapping from OS to CernVM image should be taken from LbPlatformUtils2021-11-04T09:49:39+01:00Maciej Pawel SzymanskiThe mapping from OS to CernVM image should be taken from LbPlatformUtilsThe following discussion from !60 should be addressed:
- [ ] @clemenci started a [discussion](https://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/merge_requests/60#note_4671698): (+2 comments)
> The mapping from...The following discussion from !60 should be addressed:
- [ ] @clemenci started a [discussion](https://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/merge_requests/60#note_4671698): (+2 comments)
> The mapping from OS to CernVM image should be taken from [LbPlatformUtils](https://gitlab.cern.ch/lhcb-core/LbPlatformUtils/-/blob/master/LbPlatformUtils/inspect.py#L46-53)https://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/issues/17Enable to build from sources on CVMFS2021-12-01T14:52:28+01:00Maciej Pawel SzymanskiEnable to build from sources on CVMFShttps://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/issues/16produce a usable installation even after a build failure2021-09-17T10:01:22+02:00Marco Clemencicmarco.clemencic@cern.chproduce a usable installation even after a build failureCMake, by default, requires that all build artifacts have been correctly produced when installing.
It's possible to tell CMake that a build artifact is `OPTIONAL`, but it's not easy nor correct to change all invocations of the `install`...CMake, by default, requires that all build artifacts have been correctly produced when installing.
It's possible to tell CMake that a build artifact is `OPTIONAL`, but it's not easy nor correct to change all invocations of the `install` command to use the `OPTIONAL` flag (we risk to deploy incomplete builds without noticing).
What we can do is to patch the CMake generated `cmake_install.cmake` files in the nightlies so that we can effectively turn all build artifacts to `OPTIONAL` in the special case of the nightly builds.
See lhcb-core/LbNightlyTools#98https://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/issues/15extend elasticsearch configuration to support custom CA certificates2021-09-02T12:09:40+02:00Marco Clemencicmarco.clemencic@cern.chextend elasticsearch configuration to support custom CA certificatesWe are going to use a CERN IT elasticsearch instance which has a certificate that is not standard, so we need to pass the path to the CA certificate when instantiating the client.
The configuration should look like:
```yml
elasticsearch...We are going to use a CERN IT elasticsearch instance which has a certificate that is not standard, so we need to pass the path to the CA certificate when instantiating the client.
The configuration should look like:
```yml
elasticsearch:
uri: "http://...@elasticsearch..."
ca_certs: "/path/to/file.pem"
```
where `ca_certs` is optional.
The value of `ca_certs` will have to be passed to the `Elasticsearch` constructor.
Another option would be to change the configuration to be
```yml
elasticsearch:
hosts: ["http://...@elasticsearch..."]
verify_certs: true
ca_certs: "/path/to/file.pem"
```
so that we can write in Python
```py
Elasticsearch(**config["elasticsearch"])
```
but this binds ourselves too tightly to a specific implementation... although it's very unlikely we use another one, so probably we should do the change now.Maciej Pawel SzymanskiMaciej Pawel Szymanskihttps://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/issues/14Add support for CTest attachments and notes2021-07-23T18:09:18+02:00Marco Clemencicmarco.clemencic@cern.chAdd support for CTest attachments and notesCTest is able to submit [attachments](https://cmake.org/cmake/help/latest/command/ctest_test.html#attached-files) and [notes](https://cmake.org/cmake/help/latest/manual/ctest.1.html#dashboard-client) to the CDash dashboard.
We should su...CTest is able to submit [attachments](https://cmake.org/cmake/help/latest/command/ctest_test.html#attached-files) and [notes](https://cmake.org/cmake/help/latest/manual/ctest.1.html#dashboard-client) to the CDash dashboard.
We should support those special operations by uploading the *attached files* and the *notes file* to the test log directory.https://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/issues/13Modify generate_build_report to use the new dictionary instead of a log file2021-07-21T14:17:51+02:00Marco Clemencicmarco.clemencic@cern.chModify generate_build_report to use the new dictionary instead of a log fileThe following discussion from !54 should be addressed:
- [ ] @clemenci started a [discussion](https://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/merge_requests/54#note_4599713):
> About the frontend understandi...The following discussion from !54 should be addressed:
- [ ] @clemenci started a [discussion](https://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/merge_requests/54#note_4599713):
> About the frontend understanding the new structure, we first have to change [generate_build_report](https://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/blob/8a326eaf6c358f4032342299b0eb8e9a30abae84/lb/nightly/functions/build_log.py#L621) to use the new dictionary as input instead of the dump.
>
> At that point we should decide how we format the new report and teach the frontend to display it.
>
> But in another MR.https://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/issues/12Add more statistics to the build command reports2021-07-21T14:17:51+02:00Marco Clemencicmarco.clemencic@cern.chAdd more statistics to the build command reportsThe following discussion from !54 should be addressed:
- [ ] @clemenci started a [discussion](https://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/merge_requests/54#note_4599669):
> We should could have something ...The following discussion from !54 should be addressed:
- [ ] @clemenci started a [discussion](https://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/merge_requests/54#note_4599669):
> We should could have something like the report of the [time](https://www.man7.org/linux/man-pages/man1/time.1.html) command. `time` (the command not the bash builtin) allows you to customize the report so we could make it print (or write to a temporary file) what we want (elapsed time, system time, user time, memory, ...), even directly as a Python dictionary:
> ```
> ❯ \time -f '{"duration": "%E", "maxresident": %M}' sleep 1
> {"duration": "0:01.00", "maxresident": 576}
> ```
> In principle we could store all the metrics that `time` records, but that would probably be too much. Better to store just some basic info like time, memory and average cpu.https://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/issues/11Review the use of decode and encode of unicode strings2021-06-28T18:12:09+02:00Marco Clemencicmarco.clemencic@cern.chReview the use of decode and encode of unicode stringsIn general we cannot be sure that the stdout/stderr of the commands we call is valid unicode, so we have to protect all `bytes.decode` invocations with `errors="surrogateescape"`, and make sure that all the matching `str.encode` also use...In general we cannot be sure that the stdout/stderr of the commands we call is valid unicode, so we have to protect all `bytes.decode` invocations with `errors="surrogateescape"`, and make sure that all the matching `str.encode` also use `errors="surrogateescape"` (see https://docs.python.org/3/library/codecs.html#error-handlers)
- [ ] @clemenci started a [discussion](https://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/merge_requests/54#note_4607226):
> As discussed on the chat, we cannot be sure that the output of our commands is valid unicode, so it's better to use:
> ```suggestion:-1+0
> output["stdout"] = result.stdout.decode(errors="surrogateescape")
> output["stderr"] = result.stderr.decode(errors="surrogateescape")
> ```https://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/issues/10Add automatic retry of failed tests (in CMake builds)2021-03-15T12:42:23+01:00Marco Clemencicmarco.clemencic@cern.chAdd automatic retry of failed tests (in CMake builds)see lhcb-core/LbNightlyTools#89see lhcb-core/LbNightlyTools#89https://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/issues/9support CMT builds2021-07-28T12:29:34+02:00Maciej Pawel Szymanskisupport CMT buildshttps://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/issues/8get dependencies needed to build the project2021-04-20T16:30:59+02:00Maciej Pawel Szymanskiget dependencies needed to build the projectAt the moment, the build script does not take into account dependencies within the slot, so we need to add the functionality to download and unzip the build artifacts needed by the project that we currently build. We could use for that e...At the moment, the build script does not take into account dependencies within the slot, so we need to add the functionality to download and unzip the build artifacts needed by the project that we currently build. We could use for that e.g. `multiprocessing`.https://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/issues/7collect build messages only from build (or all in old cmake) step2021-01-20T12:20:59+01:00Maciej Pawel Szymanskicollect build messages only from build (or all in old cmake) stepWe don't need to run e.g. `configure` or `install` within `lb-wrapcmd` since the output is quite big. Then, we probably don't need to compress the data sent through the socket.We don't need to run e.g. `configure` or `install` within `lb-wrapcmd` since the output is quite big. Then, we probably don't need to compress the data sent through the socket.https://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/issues/6add LbDevTools to dependencies2021-11-03T16:14:34+01:00Maciej Pawel Szymanskiadd LbDevTools to dependencieswaiting for https://gitlab.cern.ch/lhcb-core/LbDevTools/-/issues/55
The following discussion from !7 should be addressed:
- [ ] @clemenci started a [discussion](https://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/me...waiting for https://gitlab.cern.ch/lhcb-core/LbDevTools/-/issues/55
The following discussion from !7 should be addressed:
- [ ] @clemenci started a [discussion](https://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/merge_requests/7#note_3934641): (+2 comments)
> This is definitely wrong, as it can only work with LbScripts.
>
> We should replace this call with an `lb-project-init` equivalent call using the version of `LbDevTools` requested for the build.https://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/issues/5Add checkout of data packages2020-11-18T08:53:50+01:00Marco Clemencicmarco.clemencic@cern.chAdd checkout of data packagesMarco Clemencicmarco.clemencic@cern.chMarco Clemencicmarco.clemencic@cern.chhttps://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/issues/4Review where rpc.checkout creates the temporary files2021-02-19T14:23:57+01:00Marco Clemencicmarco.clemencic@cern.chReview where rpc.checkout creates the temporary filesThe following discussion from !5 should be addressed:
- [x] @clemenci started a [discussion](https://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/merge_requests/5#note_3640127): (+1 comment)
> It's probably bette...The following discussion from !5 should be addressed:
- [x] @clemenci started a [discussion](https://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/merge_requests/5#note_3640127): (+1 comment)
> It's probably better to use a *proper* temporary file.https://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/issues/3Use SoftConfDb to get Gitlab URL of projects2021-03-15T12:41:28+01:00Marco Clemencicmarco.clemencic@cern.chUse SoftConfDb to get Gitlab URL of projectsThe following discussion from !5 should be addressed:
- [ ] @clemenci started a [discussion](https://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/merge_requests/5#note_3640125):
> the default Gitlab Git URL shoul...The following discussion from !5 should be addressed:
- [ ] @clemenci started a [discussion](https://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/merge_requests/5#note_3640125):
> the default Gitlab Git URL should be retrieved from SoftConfDbhttps://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/issues/2Evaluate and possibly use replacement of zip command with zipfile module2022-05-25T10:01:56+02:00Marco Clemencicmarco.clemencic@cern.chEvaluate and possibly use replacement of zip command with zipfile moduleThe following discussion from !5 should be addressed:
- [ ] @clemenci started a [discussion](https://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/merge_requests/5#note_3639250):
> Should we use the `zip` command ...The following discussion from !5 should be addressed:
- [ ] @clemenci started a [discussion](https://gitlab.cern.ch/lhcb-core/nightly-builds/lb-nightly-functions/-/merge_requests/5#note_3639250):
> Should we use the `zip` command or the `zipfile` module? (see 6c34b21ac)