search

ros-infrastructure / prerelease_website

1 stars 5 forks source link

Generated commands look the same no matter what branch option selected #31

Closed 130s closed 7 years ago

130s commented 8 years ago

(May or may not be related to #14)

I flipped devel and latest but in the end I seem to have gotten the exactly same command.

Also chose specific version tag but it looks the same again.

Question: Will the result of these command be actually different with these commands (if so, the change is embedded somehow somewhere invisible from the command)?

dirk-thomas commented 8 years ago

I can confirm that the version selection doesn't work at the moment. It seems to be a regression of the "new" UI. @wjwwood Can you please look into this at some point.

wjwwood commented 8 years ago

I'll try to have a look at it soon.

wjwwood commented 8 years ago

It doesn't look like the underlying generate_prerelease_script.py script can do this. I guess I just never noticed that this information was not used to modify the end script.

Currently, I believe it will always checkout code as defined in the devel section of the rosdistro distribution.yaml file.

@dirk-thomas Can you speak to whether or not the generate_prerelease_script.py is capable of getting the released version of the repository's packages? I see that you can override the repository url and branch for each "repository name", but since there is a branch for each package in the release case, this is not sufficient to do the "latest" or "<version>" options, as it would need to make a mapping from the repository name to several branches rather than just one. I looked at the output of --help and at the documentation here:

https://github.com/ros-infrastructure/ros_buildfarm/blob/5141d5dba2993718a363475abf86edbb0e958346/doc/jobs/prerelease_jobs.rst

But I couldn't find anything that lead me to a way to accomplish this. I think something could be done with the underlay folder, but I'm not sure.

130s commented 8 years ago

it will always checkout code as defined in the devel section of the rosdistro distribution.yaml file.

That explains to me why prerelease stops with error saying like the following for a repo without source entry, even though on prerelease web i/f I selected latest:

The repository 'moveit_resources' does not have a source entry in the distribution file. We cannot generate a prerelease without a source entry.

dirk-thomas commented 7 years ago

The script generate_prerelease_script.py has the following relevant options to override the branch / repo (see its --help output):

Using those the generated command lines for the some other examples (since moveit_core is not a repo anymore) should be:

As you can see in the last two commands each package is being identified individually.

wjwwood commented 7 years ago

The use of genmsg is not very demonstrative, since it only has one package in the repository. I did nodelet_core:

generate_prerelease_script.py \
  https://raw.githubusercontent.com/ros-infrastructure/ros_buildfarm_config/production/index.yaml \
  kinetic default ubuntu xenial amd64 \
  --level 0 \
  --output-dir . \
  --custom-repo \
    nodelet_pkg:git:https://github.com/ros-gbp/nodelet_core-release.git:release/kinetic/nodelet/1.9.8-0 \
    nodelet_core_pkg:git:https://github.com/ros-gbp/nodelet_core-release.git:release/kinetic/nodelet_core/1.9.8-0 \
    nodelet_topic_tools_pkg:git:https://github.com/ros-gbp/nodelet_core-release.git:release/kinetic/nodelet_topic_tools/1.9.8-0

This would work, but I think the important thing to point out is that rather than specifying the repository name (as is the case for devel) in the other two cases you must omit the repository name and only specific the exact repository/branch pairs to clone using --custom-repo. This is a lot more work for the web tool to handle because now it must figure out what packages were released for packages in each other option, i.e. latest and <specific version>. I don't know when I'll have time to do that.

I think _pkg suffix you used in the first field of --custom-repo seems to just be a convention. In fact the first field of --custom-repo should probably just be called "local folder name" because I think that's really all it is.

dirk-thomas commented 7 years ago

I just made up genmsg_pkg to clarify it doesn't correlate with the repo name in any way. I good convention would be to use the package name. It is already guaranteed to be unique.