Feature ideas

Currently in Gitlab V2 The integration supports syncing group's members. However, this only includes members with direct membership and excludes members with inherited membership. i.e a member who has access to a group by inheriting access from a parent group. The same applies to projects, the integration does not include projects members both direct and Inherited (These are members with access to a project by being a member of a group) Proposed Improvement: To acquire full visibility into a groups and projects members, Enhance the integration to support including inherited members in projects and groups.

Currently, the ArgoCD integration does not work well for clusters that are known to be off somewhat frequently. To handle this, it would be nice to either: Adjust the ArgoCD integration, add handling that will silently continue when a request fails (or with shorter backoff), or Add handling to the Ocean framework that will either: Silently continue, Reduce the number of retries, or Reduce the backoff period when a request fails

The Ocean integration should support the following kinds in addition to what is currently supported. Builds Tests (runs and results) i.e Unit Tests Code Coverage Pipeline Stages Pipeline Runs Deployments Environments Although some are supported through ADO service hooks, this requires the user to configure them outside of the Ocean integration.

Today we have a static and strict small schema we bring about users and teams when integrating with an identity provider (user names, mails, team names) The idea here is to have the whole payload coming from the SSO provider (the schema should be known based on the SSO protocol) and for Port builders to be able to decide what they want to map to the user and team blueprints.

In GitLab v2 , discovery calls now use a fixed setting of min_access_level=30 (Developer). Because of this, service or admin tokens cannot access projects unless they are added as members to each group or project. By contrast, In GitLab v1 , the filterOwnedProjects:false flag made it possible to include projects where the token was not an owner or member, using admin or auditor tokens with built-in read permissions. For enterprises managing thousands of projects, this change is not scalable due to: Security and privacy concerns – service accounts would become visible across all groups. Operational overhead – maintaining explicit membership for thousands of projects is not feasible. Proposed Solution : Re-introducing the filterOwnedProjects:false flag (which bypasses min_access_level), OR. Allowing users to configure min_access_level instead of enforcing it at Developer. This would enable users to use admin/auditor tokens without explicit project membership.

It would help a lot to have it instead of having to write scripts to get the data. Especially to handle deletions

Add the secret-scanning-alerts kind to the Github Ocean (self-hosted) integration.

We prefer to deploy through certified marketplace listings for easier deployment and compliance.