search

robust-rosin / robust

A dataset of 200+ bugs in the Robot Operating System for BugZoo
30 stars 9 forks source link

Use bugzoo/fork-url param for all bugs #163

Open Chamango90 opened 5 years ago

Chamango90 commented 5 years ago

Currently if the bugzoo/fork-url param (in *.bug description) is not set build-bugzoo.py would look at the name of the bug's folder and use that as a lookup in a hardcoded dict. Problem arise if any bug is moved into another folder like e.g. one with the git-hash's name. Then, the lookup fails and currently also the program terminates. Creating the fork-url out of the
"https://github.com/robust-rosin/"+desc["time-machine"]["ros_pkgs"] would also work, however this would be very specific to the robust project and only guessing.

Thus, to assure that the build-bugzoo.py is a) more flexible and b) more stable one, we decided in today's telco to use the bugzoo/fork-url param for all bugs. (Maybe as a list? This I did not understand fully)

This requires:

Example of an error (here I would need the repo cob_control):

$ python build-bugzoo.py 
generating manifest for bug [care-o-bot:description] at file (/...../robust/care-o-bot/description.bug)
Traceback (most recent call last):
  File "../../scripts/build-bugzoo.py", line 136, in <module>
    main()
  File "../../scripts/build-bugzoo.py", line 74, in main
    })[package]
KeyError: 'care-o-bot'

@ChrisTimperley , @gavanderhoorn this could also be an option which would save us the work to add a param to every *.bug. What do you think?

# new param: fork_base_url
robust_base_url =  desc["bugzoo"]["fork_base_url"]  or "https://github.com/robust-rosin/"
url_fork = robust_base_url + desc["time-machine"]["ros_pkgs"]
gavanderhoorn commented 5 years ago

I would personally prefer to be as explicit as possible, and have all the information to parse a .bug file in that same file. That way they are free from dependencies on external information or assumptions (ie: that the commits they refer to may be found in some repository that one should know the location of when interpreting the .bug file).

Yes, that will lead to some duplication of information, but I believe that is ok in this case.

As an side: we could add the field to the existing .bug files by doing the same thing that @ChrisTimperley's script does now: assume that the name of the fork can be derived from the location/name of the file/pkgs involved and then add that as a first "guess". A relatively simple script could do this for all .bug files.

That would reduce the job of adding the new field to one of checking that the value(s) for the field are ok, which is probably less work.

ChrisTimperley commented 5 years ago

As an side: we could add the field to the existing .bug files by doing the same thing that @ChrisTimperley's script does now: assume that the name of the fork can be derived from the location/name of the file/pkgs involved and then add that as a first "guess". A relatively simple script could do this for all .bug files.

That would reduce the job of adding the new field to one of checking that the value(s) for the field are ok, which is probably less work.

I like the idea of this. I'm afraid that we do still need our .bug files to obey a consistent file structure, however: build-bugzoo.py uses the name of the parent directory when determining the Docker context for the bug. Put another way, build-bugzoo.py assumes that all .bug files for a given package are located at the root directory for that package.

gavanderhoorn commented 5 years ago

Just to clarify: my observation was just that we could reduce the manual labour of adding the new field to all the bugs "manually" if we could write a simple script adding the new field and setting its contents.

It was not meant as anything else.

gavanderhoorn commented 5 years ago

Put another way, build-bugzoo.py assumes that all .bug files for a given package are located at the root directory for that package.

Is there a specific reason for this? Can it not list directories recursively?

ChrisTimperley commented 5 years ago

Put another way, build-bugzoo.py assumes that all .bug files for a given package are located at the root directory for that package.

Is there a specific reason for this? Can it not list directories recursively?

Finding the .bug files isn't the problem. Locating the corresponding directory for each bug (i.e., the directory containing the test.sh and deps.rosinstall) is the part that requires assumptions.

gavanderhoorn commented 5 years ago

Ah, ok. Then I'd misunderstood.

Yes, an assumption that the other artefacts required to reproduce a .bug are located relatively to the .bug itself would be perfectly valid.

I was confused by the "all .bug files for a given package" bit.

If all .bugs live in their own directory, would that work (ie: everythin in that directory, ex the .bug itself, is for the reproduction)?

ChrisTimperley commented 5 years ago

Ah, ok. Then I'd misunderstood.

Yes, an assumption that the other artefacts required to reproduce a .bug are located relatively to the .bug itself would be perfectly valid.

I was confused by the "all .bug files for a given package" bit.

If all .bugs live in their own directory, would that work (ie: everythin in that directory, ex the .bug itself, is for the reproduction)?

That's good with me.

Either way, I've added some additional checks to build-bugzoo.py to print a warning if those additional artefacts aren't at their assumed locations: https://github.com/robust-rosin/robust/pull/166/commits/819010e9ab913932af3e5118a15b59b6eaca5c18.