Subscriptions for multiple projects

Hi,

i have set up a notification mechanism, that uses two separate permission groups to distinguish failed and successful builds.I customized the templates to my desire. It’s up and running :slight_smile:

However i need to create explicit subscriptions for all projects of the Team. It’s not hard work, but stupid repetition. It would be great to define a group of projects that are developed by a Team. And to set up only one subscription for that one group. We have multiple Teams, where a Team can maintain multiple projects.

Thomas

A similar request was made recently to allow selection of multiple configurations and/or projects as the source for each subscription. We are looking into changing the Source select box to a multi-select box. There’s quite a lot on underlying changes to make to support this, but it’s now high on our list of priorities.

1 Like

Hi Dave,

as i understand your proposal, it is limited to subscriptions. How about a general approach of grouping projects. That would give more options in other areas. As for subscriptions you would simply add an option to select “meta-groups”, for example by extending the select box.

Thomas

Hi Thomas,

Projects are currently a grouping of configurations. Generally we would suggest that the projects are used to group the configurations used for a team.

We also have an item on our to-do list to allow configurations to be tagged. Once this is implemented it will allow a configuration to be a member of multiple ‘groupings’. This is primarily being developed for filtering the dashboard views but could also be used as a source for subscriptions in due course.

We have:

  • multiple apps
    Apps do use their own versioning having non-related repositories.
  • multiple projects
    Projects usually build one app only or a group of related apps.
  • multiple teams
    Each team is responsible for one or more projects.

Right now we define one CCI project for each of our projects. Using separate configurations for assigning versions to each of them. This works well for us.

Reorganizing all of this, just to have one project with many (non-related) configurations is possible. I don’t think, that we will use this approach though.

Thomas