action #10192

Improve source code window

Added by okurz about 4 years ago. Updated about 1 month ago.

Status:WorkableStart date:12/01/2016
Priority:LowDue date:
Assignee:-% Done:

0%

Category:Feature requests
Target version:QA - future
Difficulty:
Duration:

Description

acceptance criteria

  • The source code window shows the test code that was executed, not the current
  • Further information about changes in git can be easily found

suggestions


Related issues

Related to openQA Project - action #8084: show source of imported modules New 01/07/2015
Related to openQA Project - action #58184: [epic][use case] full version control awareness within op... Blocked 23/03/2018
Duplicated by openQA Project - action #50498: add link to github sources Rejected 17/04/2019

History

#1 Updated by okurz about 4 years ago

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.

#2 Updated by coolo about 4 years ago

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

#3 Updated by RBrownSUSE about 4 years ago

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)

#4 Updated by coolo about 4 years ago

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

#5 Updated by RBrownSUSE about 4 years ago

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

#6 Updated by okurz about 4 years ago

  • Status changed from New to In Progress
  • Assignee set to okurz

Yes, what RBrownSUSE said plus: The main reason I propose github is because openQA is web centered. Our code lives in github. Instead of trying to build everything regarding source window (+ git commit information + history + blame + PRs) into our own code we can just link to github.

I am assigning this to me as I was playing with this over the weekend and will show you a simple proof of concept. Then I am open for further feedback and you can tell if you like the "github" approach more or better "do it on our own".

#7 Updated by coolo about 4 years ago

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

#8 Updated by coolo about 4 years ago

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.

#9 Updated by lnussel about 4 years ago

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.

#10 Updated by okurz about 4 years ago

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):

openQA github screenshot

Tell me what you like or dislike about it

#11 Updated by coolo about 4 years ago

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

#12 Updated by okurz@suse.de about 4 years ago

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.

#13 Updated by maritawerner about 4 years ago

  • Assignee deleted (okurz)

#14 Updated by coolo over 2 years ago

  • Status changed from In Progress to New
  • Target version set to future

I'm only at 80% of declining - there are other source view enhancements in the queue though. So possibly together this makes up a proper story

#15 Updated by okurz almost 2 years ago

  • Target version changed from future to future

#16 Updated by coolo 12 months ago

#17 Updated by okurz 10 months ago

  • Category changed from 124 to Feature requests

#18 Updated by okurz 8 months ago

  • Blocks action #54965: Cannot inspect the source code of the tests from my fork added

#19 Updated by okurz 6 months ago

  • Related to action #8084: show source of imported modules added

#20 Updated by okurz 6 months ago

  • Related to action #58184: [epic][use case] full version control awareness within openQA, e.g. user forks and branches added

#21 Updated by okurz about 1 month ago

  • Status changed from New to Feedback
  • Assignee set to okurz

https://github.com/os-autoinst/openQA/pull/2761 as the next feature after #54965 to use unique git hash when possible.

#22 Updated by okurz about 1 month ago

  • Blocks deleted (action #54965: Cannot inspect the source code of the tests from my fork)

#23 Updated by okurz about 1 month ago

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

#24 Updated by okurz about 1 month ago

  • Status changed from Feedback to Workable
  • Assignee deleted (okurz)

Can be followed on by others as well.

Also available in: Atom PDF