QA (public) » openQA Project (public)

I would guess there were more urgent tickets preventing someone from picking this up within our usual 30 days. If you took a look and had open questions, might be worth discussing again, though.

livdywan wrote in #note-16:

Waiting for a response for now

No response so far. Might just need to wait for Scott to make time for it.

Waiting for a response for now

No response so far. Might just need to wait for Scott to make time for it.

Asked once more.

Let's wait for Liv to return from vacation next week!?!

Discussed in the unblock

• https://github.com/os-autoinst/openQA/pull/5175 rebased
• I dropped the use of File::Touch which we don't depend on (I was confused by the CI results but the fix was straightforward)
• Looking into coverage gaps which are now also visible on the PR
  • Most importantly the candidates view
  • Needle editing looks to be using the new code, too, but is not required
  • Check how to reproduce the new feature manually e.g. using NEEDLES_DIR/other test vars (same in unit tests)

I've created a rebased version of the pr opened by @livdywan https://github.com/os-autoinst/openQA/pull/6097

• Ensure that we have 100% coverage
• finalize the wording used in the config file "correct version" vs branch/commit/sha
• Clarify if @mkittler's comment was addressed regarding "fetched by the web UI"

1/3 done, tests currently being added and reviewed

[ ] Ensure that we have 100% coverage
[x] finalize the wording used in the config file "correct version" vs branch/commit/sha
[x] Clarify if @mkittler's comment was addressed regarding "fetched by the web UI"

With the commit fd4e2469 there are only 3 missing lines to cover that can be seen in codecov. I've already created the test to cover them here, but I think I'm missing the correct endpoint api.

Reviewing the current state of the PR

• _create_tmpdir_for_needles_refspec performs network access every time it is called
  • git fetch
  • vars.json is read but never saved
• there is currently no feature flag for this
• consider "our" ticket #157159 about candidate needles in the diff view
• maybe this PR should exclude the needle editor
  • revert changes to the edit function
• review the current state of tests for the needle editor that would cover the case here

livdywan wrote in #note-39:

Reviewing the current state of the PR

• _create_tmpdir_for_needles_refspec performs network access every time it is called
  • git fetch

That is already adressed but I haven't pushed it yet

• vars.json is read but never saved

Apart from the worker saving it.
It would be much more efficient if we could write that fields back to the database on job finish,
so that we don't need to parse a json file for each needle.
That should be done on job finish, though - maybe with a whitelist of job settings that
should be written from vars.json back to the database.

• there is currently no feature flag for this

What is [scm git]->checkout_needles_sha in the config then?

Opened https://github.com/os-autoinst/openQA/pull/6190

Since this came up in the 5 Whys, can we clarify if we want #157159 on the backlog now (or next) and how it relates to this feature? Maybe we should at least estimate the ticket to be clear on what we need to know?

Now that I see that there is a PR on only showing the correct ref for the matched needle in the step https://github.com/os-autoinst/openQA/pull/6190
I would like to reconsider some points:

1. We are passing the complete file path to the json file in the needle url. If I look into the code, it's checking already if it is a subdir of share/tests anyway, so we can just leave off that path. I don't consider full paths in urls a good thing
2. For just showing the test step with the matched needle, we don't need a local cache, I believe. We can just do a redirect to https://raw.githubusercontent.com/user/repo/sha/file.png in OpenQA::WebAPI::Controller::File::needle(), saving local space and traffic. I got it working locally with a hardcoded sha. Also other git providers provide a raw image view.

This way we could easily enable the feature without having to fear a lot of traffic.

For the needle editor: For that we would probably need the json as well, so we need to fetch content from git here. But this is used rarely compared to showing module steps, and only by logged in users, so we probably can enable this as well.

For the candidates list: We need a full needle directory to get all the candidates. But maybe this could be implemented as a feature on request, e.g. having a button on a test saying "This test is based on an older git sha. Show needle candidates based on this sha instead". This way by default we would also not have to fear any additional traffic.

dheidler wrote in #note-49:

Regarding 2.:

The githubusercontent hotlinking is a nice addition but of course github specific so it would be different for github vs. gitlab vs. forgejo (and no easy way of distinguishing between the last two of them apart from public instances like codeberg.org and gitlab.com).

That can be configured with a simple mapping in the openqa.ini. No big effort.

We would also still need the code from the current PR as not every git forge has a webui at all.
And even with github a manual override might be required as the repo might be set to private.

The question is if we really need this. Using githubusercontent would be relatively easy to implement and it would be easy to enable without having to fear traffic, and we might never need to support private repos.

So in the end we would have easier code here.

But the code for plain git is already here in the PR.
All the work is done.
And it is optional to enable it.
Why throw it away?
For the sake of having less code? I don't think so.

The githubusercontent hotlinking sounds like a good idea that will be propably what we will be using.
But I would like to have both options as merging the existing PR is now zero effort.

As per discussions yesterday I assume you're wrapping up https://github.com/os-autoinst/openQA/pull/6190 as planned, right? And the proof of concept mentioned in #177817 will be an optimization that's not making this obsolete.

I wasn't sure what the teams opition was on that but sure.

tinita wrote in #note-47:

For the candidates list: We need a full needle directory to get all the candidates. [...]

I just tried out the code again and realized this works already fine for the candidates list.
I remember a conversation where Marius said that for the needle candidates we would need to check out that ref to be able to determine all the possible needle candidates, but all the necessary information is stored in details-modulename.json already. Maybe I misunderstood? Why was nobody correcting my above assumption? :)

https://github.com/os-autoinst/openQA/pull/6229