Can I integrate a public GitHub repository with a trial RTC repository on jazz.net?
I am trying to do a proof of concept of the integration between RTC and GitHub where RTC uses the GitHub repo as its SCM repository.
First of all, is this possible, can these two entities comunicate with each other? I have validated that I can reach both using an SSL checker.
If a valid use case, then:
I have created a public GitHub repo and a trial RTC project area on Jazz.net. I have configured the projects according to my understanding of the instructions:
I have created the GH repo and have created a webhook, which uses the payload URL of:
Content Type: application/json
Secret Key is the one that I specified in RTC when registering the GH repo.
SSL verification is enabled.
I have registered the GH repo with the RTC project area:
Key: fee99ab174fa44b6a50a0ba4fb50e3ad
GitHub Server Authorization Details:
Secret Key: defined
Git Server Authentication Details ( are both supposed to be defined or only one?)
GH username
GH "Personal Access Token" instead of password
Nothing under Advanced and nothing under Mapped Git References.
In the RTC Project Area the Everyone role has been given all Git permissions:
The "Require Work Item Hint Commit Comment" pre-condition has been defined: Always, Everyone
GitHub requests are Authorized
When I look at the details of the attempted deliveries in the webhook section of the GH repo I see a Requests tab but no Response tab.
I only get: "Couldn't resolve host name"
|
One answer
Hi Ryan
I just created a quick test and it works well. The payload URL seems incorrect, it is missing the hostname (which might explain why you are getting a hostname not found error) and also the user ID field (need if the RTC User and Github userIds are different) and the Github URL may not need the.git at the end. Could you try these changes?
1 - Payload URL:
2- Registered Git URL
Comments Hi Shubjit,
Thank you for that information. I had the same thought and modified the URL that I got from the IBM documentation to include the actual hostname and it did work. What I found though was that it would update the WI with the link to the GIt commit if I included the WI #, as expected, BUT it did not prevent the push from taking place if I left out the WI # on the commit. It is my understanding that the webhook is supposed to FORCE the WI # to be included and if not, prevents the push. Is that how you understand it and in your test, did you see that behavior?
Hi Ryan
I feel that the Pre Conditions / process enforcement might not work in the current version 6.0.4 and earlier. I can commit with the WI# as well with the Precondition setup.
The documentation for 6.0.5 is updated regarding the process enforcement, if you are on a Release Candidate version of 6.0.5 on your jazz.net cloud, you could try the new configurations.
https://www.ibm.com/support/knowledgecenter/SSYMRC_6.0.5/com.ibm.team.connector.cq.doc/topics/t_git_hub_prereceive.html
Best Regards
Shubjit
Shubjit,
Thank you for the quick response. I went to that link that you sent and there I see this statement:
"A user ID between GitHub and Rational Team Concert must match for process enforcement."
Do you know if this simply means that the id text needs to be the same, "ryanmcbryde" vs. "rmcbryde" or do you think that it means that they need to share an LDAP, or other external source, id?
Can process enforcement work WITHOUT server side hooks?
Do I have to use the nodeJs server approach?
Hi Ryan
Without server side hooks the Pre-conditions would not work. Even if the UserId and LDAP is the same for RTC and Github configurations, it would not to work in 6.0.4 or below with Webhooks alone.
You need to deploy server pre-receive hooks and this feature for Github (and GHE) was added in RTC 6.0.5.
The NodeJS approach would mean that you host your Git Repo with a nodejs server, So you need access to the gitrepo on the filesystem.
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.