QA » openQA Project

see https://github.com/okurz/show_github_source for an example how to do it with python-Flask. I guess with mojolicious it would be pretty similar.

why would you grab github instead of using your local git checkout?

coolo wrote:

why would you grab github instead of using your local git checkout?

I assume (ie. I have no idea but I'm going to write this comment anyway) because the longer-term goal would be to provide tools/links so people can see the diff between the executed tests and the currently available tests - so people can easily know the change is out of date and make an informed decision about re-running it or not

Using a local git checkout might make some of that information harder to get to (eg. PR with comments and such)

So what is the user story? "Further information about changes in git can be easily found" is all or nothing.

User Story

=openQA Reviewer=
an openQA reviewer wants to be able look at the Source Code window and see the version of the code that was executed in that test, in order to understand the behaviour that they are seeing in the logs, video and the screenshots

If the version of the executed code is different from either the latest available version (ie. the newest in github) or the latest deployed version (ie. the newest in local git) the openQA reviewer needs to know this in order to decide whether action is necessary to fix the problem, or just to re-run the test

=Release Manager/Developer/Casual Reviewer=
Same as the openQA reviewer, but without the abilility to reschedule the test, however knowing the issue has been changed (or not) could reduce noise towards the team and/or help encourage improvements to the Code - which is a reason for a link to the 'upstream' github instead of just relying on the local git

"Our code lives in github" - might be true for SUSE, but openQA's goal was never to be 100% for SUSE only.

And please make sure #8084 is implemented - which I consider more important than being able to follow the PR discussion within openQA.

I can see the requirement to record the commit id of the test run, but having a (configurable) external link to show that diff is IMO more than enough.

I'm not sure I like that either. There must be an offline/internal version of the source code viewer at least. Providing a convenience link to whatever external source repo provider would be fine but loading and embedding stuff from elsewhere directly makes me nervous.

lnussel wrote:

There must be an offline/internal version of the source code viewer at least

why?

this is what I came up with as a proof of concept yesterday evening (leisure project):

Tell me what you like or dislike about it

Again: how to implement 8084 if the source viewer is external app?

On Tuesday 19 January 2016 14:20:26 you wrote:

[openSUSE Tracker]
Issue #10192 has been updated by coolo.

Again: how to implement 8084 if the source viewer is external app?

I don't know and I don't see this related. I do not necessarily want to
replace the source code view that we have but provide another alternative. If
the other modules are important why not grep the log-file for every line that
was executed and provide this as an execution path? I see this is as a
different use case but all are helpful.

After #54965 done and with https://github.com/os-autoinst/openQA/pull/2761 which we already have deployed on o3 and osd and working nicely for custom checkouts I have the following ideas as alternatives:

1. Don't change anything for non-git stuff and call it legacy
2. Try to reference from local git checkouts if .git can be found in distri dir