action #105918
openo3 logreports - fatal: Invalid revision range sha1..sha2
0%
Description
We see the following warnings/errors on o3:
# /var/log/openqa
[2022-02-02T14:57:17.829870Z] [info] [pid:17681] Running cmd: git -C /var/lib/openqa/share/tests/opensuse log --stat --pretty=oneline --abbrev-commit --no-merges 9859c7ec551416fbc16c19966a303282f3bb9fc7..5a282b23152
7413a71c229ae38b180b44e5b97a6
[2022-02-02T14:57:17.881979Z] [warn] [pid:17681] fatal: Invalid revision range 9859c7ec551416fbc16c19966a303282f3bb9fc7..5a282b231527413a71c229ae38b180b44e5b97a6
[2022-02-02T14:57:17.882152Z] [error] [pid:17681] cmd returned 32768
[2022-02-02T14:57:17.882350Z] [info] [pid:17681] Running cmd: timeout 20 git -C /var/lib/openqa/share/tests/opensuse diff --stat 9859c7ec551416fbc16c19966a303282f3bb9fc7..5a282b231527413a71c229ae38b180b44e5b97a6
[2022-02-02T14:57:17.917562Z] [warn] [pid:17681] fatal: Invalid revision range 9859c7ec551416fbc16c19966a303282f3bb9fc7..5a282b231527413a71c229ae38b180b44e5b97a6
[2022-02-02T14:57:17.917765Z] [error] [pid:17681] cmd returned 32768
...
[2022-02-04T08:38:28.275650Z] [info] [pid:25579] Running cmd: timeout 20 git -C /var/lib/openqa/share/tests/opensuse diff --stat 6ef2dd63dfbbd7413e306c43e07ae4ee366ff980..
[2022-02-04T08:38:28.312493Z] [warn] [pid:25579] fatal: Invalid revision range 6ef2dd63dfbbd7413e306c43e07ae4ee366ff980..
[2022-02-04T08:38:28.312810Z] [error] [pid:25579] cmd returned 32768
We should probably investigate why the we sometimes have a bad revision, or the second revision is empty.
Code: lib/OpenQA/Schema/Result/Jobs.pm git_diff
Updated by okurz almost 3 years ago
- Project changed from openQA Infrastructure (public) to openQA Project (public)
These are all things that could be better handled by the software itself, not infrastructure issues
Updated by tinita almost 3 years ago
- Description updated (diff)
- Target version changed from future to Ready
Updated by okurz almost 3 years ago
- Priority changed from Normal to Urgent
Very likely the problem is that the revision does not exist because a custom git repo is specified. I suggest for now to still exclude the log message from logwarn and then continue working on this at a later time. Setting to urgent to address only the logwarn alert, not the real problem. Whenever an issue has been found by logwarn we should exclude it unless the fix takes about the same time then excluding the log warn alert
Updated by okurz almost 3 years ago
- Related to action #105828: 4-7 logreport emails a day cause alert fatigue size:M added
Updated by tinita almost 3 years ago
Updated by okurz almost 3 years ago
- Priority changed from Urgent to Normal
- Target version changed from Ready to future
PR merged. That means the urgency is addressed and we can follow up with the actual feature implementation at a later time. @tinita as you have not assigned the ticket to yourself and have not stated an idea what could be done about that I assume that you are ok to move the ticket out of our backlog for now.