Restore sanity check for gh tool

[scpeters]

A sanity check for presence of the gh tool was recently added in #1436 and reverted in #1443. This is an attempt to restore the sanity check by only checking for gh in cases when a ROS vendor package PR may be opened by process_ros_vendor_package().

This should be tested before merging.

[azeey]

Worked on https://build.osrfoundation.org/job/_releasepy/307/console

[scpeters]

Worked on https://build.osrfoundation.org/job/_releasepy/307/console

I think that uses the master branch of release-tools

https://build.osrfoundation.org/job/_releasepy/307/parameters/

[azeey]

You're right. I only checked out your branch locally. Not sure what is a good way to test this

[scpeters]

You're right. I only checked out your branch locally. Not sure what is a good way to test this

there are multiple contexts in which release.py gets called:

1. Called by a package maintainer to tag the repo and trigger a -source build (step 1 in the release process documentation)
2. Called by the _releasepy jenkins job (see OSRFReleasepy.groovy and step 4 in the release process documentation)
3. Called by the -nightly-scheduler jenkins jobs (like https://build.osrfoundation.org/job/ignition-jetty-nightly-scheduler, which has actually been failing for the past few days, I guess it's not in the build farmer dashboard)

[scpeters]

3. Called by the -nightly-scheduler jenkins jobs (like https://build.osrfoundation.org/job/ignition-jetty-nightly-scheduler, which has actually been failing for the past few days, I guess it's not in the build farmer dashboard)

to test the nightly scheduler, I first created another "broken" branch from 8fb24af (without the fix in e1c2ef3) and ran a dry-run nightly scheduler job, which correctly failed:

then I ran a dry-run nightly scheduler from this branch and it passed:

[scpeters]

1. Called by a package maintainer to tag the repo and trigger a -source build (step 1 in the release process documentation)

to test this, someone should try a dry-run release.py invocation without gh installed on your local system

2. Called by the _releasepy jenkins job (see OSRFReleasepy.groovy and step 4 in the release process documentation)

to test this, I think we would need to run a -source job with the proper RTOOLS_BRANCH parameter, since I believe the downstream _releasepy job would inherit that parameter

[scpeters]

2. Called by the _releasepy jenkins job (see OSRFReleasepy.groovy and step 4 in the release process documentation)

to test this, I think we would need to run a -source job with the proper RTOOLS_BRANCH parameter, since I believe the downstream _releasepy job would inherit that parameter

if we added --rtools-branch as a parameter to release.py, we could copy it to params["RTOOLS_BRANCH"] where the other params are set

[j-rivero]

Although the implementation works, I would prefer to avoid calling the sanity checks in the main logic and do that unconditionally at the begging. The sanity check should know if it needs to be applied or skipped. Something like master...jrivero/restore_gh_check .

I think that is going to be easier to maintain and save some lines to read in the logic.