Skip to Main Content
IBM Sustainability Software - Ideas Portal


This portal is to open public enhancement requests against the products and services belonging to IBM Sustainability Software. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Future consideration
Categories Integrations
Created by Guest
Created on Dec 23, 2020

GitLab RTC connector - preconditions should also work for web hooks

The formerly used Git/RTC Plugin used so called "pre and post commit hooks" based on python code which needed to be configured on the GitLab host itself.

The advantage on this solution is that preconditions on EWM side can be configured to work. E.g. the precondition that only Work Items can be linked which belong to the associated Project Area.

The big big disadvantage is, that if anything wents wrong on the EWM side (e.g. server down, Work Item does not exist, etc...) The push is denied on GitLab side.

This we already had several times where the development line was standing.

In version 7.0.1 the pre and post hooks based on python code seems to be gone.
Instead it is now possible to use webhooks with several new advantages:
- Linking not only from Commits but also from Issues, Merge Requests and so on possible
- Backlink from GitLab to EWM available (this is a breaking change and a really important advantage)
- No blocking on GitLab side anymore if EWM has issues (webhooks working style: fire and forget)

But one real disadvantage is that preconditions cannot be used anymore...

Please implement the behaviour of using preconditions also when using webhooks and not only when using the Gitlab / RTC connector.

Idea priority High
  • Guest
    Reply
    |
    Aug 1, 2022
    Adding an update -
    EWM RFE review board has re-evaluated this request and will continue to keep it in the Backlog as an uncommitted candidate for a future release but not the upcoming release. This request, while valid, is unlikely to be addressed in the next 8-12 months due to other higher priority items on the Backlog.
  • Guest
    Reply
    |
    Jul 15, 2022

    any news on this?

  • Guest
    Reply
    |
    Feb 26, 2021

    - The EWM RFE Review board looked at this and have accepted it as an Uncommitted Candidate on the Backlog.

  • Guest
    Reply
    |
    Feb 24, 2021

    Yes, I can confirm this.
    Since GitLab 13 there is an EWM integration directly in GitLab available (as far as I know directly from IBM) which makes it really easy to configure the linking between EWM Areas and GitLab Repositories.
    This configuration runs through webhooks only.
    The big benefit - beside the easy configuration - is, that pushing to GitLab won't fail in any case. This is like fire and forget and this is how working is preferred in development.

    Getting the preconditions to work here would combine the non blocking development with, e.g. the non linking foreign work items.

    Greetings,
    Simon

  • Guest
    Reply
    |
    Feb 24, 2021

    If I understand the requirement correctly, while web hooks are being used, preconditions should be applied. While this doesn't stop the Git operation, applying the precondition should stop the EWM operation like work item linking or commit comment replication, if the precondition fails. Could you confirm this?

    Yes, I can confirm this.
    Since GitLab 13 there is an EWM integration directly in GitLab available (as far as I know directly from IBM) which makes it really easy to configure the linking between EWM Areas and GitLab Repositories.
    This configuration runs through webhooks only.
    The big benefit - beside the easy configuration - is, that pushing to GitLab won't fail in any case. This is like fire and forget and this is how working is preferred in development.

    Getting the preconditions to work here would combine the non blocking development with, e.g. the non linking foreign work items.

    Greetings,
    Simon

  • Guest
    Reply
    |
    Feb 23, 2021

    Though the python hooks are deprecated in 70, we have the Node.js hooks as the replacement. Node.js based hooks support preconditions through pre-receive hook and work item linking through post-receive hook. Webhook support linking, issue and commit comment replication for GitLab. For GitLab, you can use Node.js hooks to achieve process preconditions through pre-receive hook and use either post-receive or web hook for work item linking. Preconditions are applied only in pre-receive hook. In Git, if a pre-receive hook fails, then the Git operation is stopped.

    If I understand the requirement correctly, while web hooks are being used, preconditions should be applied. While this doesn't stop the Git operation, applying the precondition should stop the EWM operation like work item linking or commit comment replication, if the precondition fails. Could you confirm this?