Project/configuration level costumization

[cmakara]

Hi,

Is there any way (or plan for future improvement) to be able to set that which project or configuration(preferably) related events should trigger a notification towards HipChat and which shouldn't?

Thanks
cSE

[parautenbach]

Hi there

(Pardon, I actually already replied this morning, but I see now there's no comment for some strange reason.)

You can set the events to trigger notifications from the administration page (as a global setting). It's been my assumption (and own use case so far) that one would be consistent in this manner across projects. Say for example I want started and failed events by default, I can't quite imagine why I'd disable, for example, the started event on some specific project as the exception, but I'm more than willing to listen to suggestions.

On this same administration page, you can define the default room ID (or make it none). You can then override this default room ID on a per project basis. What I could add as an enhancement, is to list the build configurations on the plugin's project configuration page to allow one to enable or disable events (notifications) for specific build configurations.

Does this answer your question? I'm not exactly sure whether you're more interested in the former or the latter.

There's a bit more information here too.

[cmakara]

Hi,

No problem, it is not a today or never kind of problem :)

So we handle our development projects as projects in TeamCity. Because of this we have various build configurations under a project, like nightly and various test configurations. We have one (more in the future) test config which runs frequently. I'd rather not pollute the chatroom with the results of this config. That's why I asked the question. I'd like to enable\disable all notifications config by config. Right now it doesn't seem necessary to set it by event type.

If you could add the configurations to the project level plugin configuration page, that would be great.

Thank you for the fast response.

[parautenbach]

Excellent, thank you. I'll then add this to the todo list.

[cmakara]

Thank you.

[klobucar]

+1 it would be nice to be able to in some configurations send a message on every success and only first success on others.

The example here being a build configuration that is a release script and always sends a message to a room on success while on a unit tests configuration it is just first success.

[parautenbach]

Hi Jonathon

The notification on first success or failure is available as a global option from yesterday in v0.6.1 (see #21). I'll add your more specific suggestion to the list.

[klobucar]

Yep, I upgraded to have that, but was unable to use it due to the case above. On a different note this is all excellent work. Thanks for putting in the work to provide the plugin.

[alextoombs]

+1, would definitely help. Thanks for all the great work so far!

[parautenbach]

Right, so to everyone that's contributed to this discussion so far, let's see if we can find something that will work.

My goal is to keep configuration minimal, but flexible. What I would like to avoid is having to navigate to too many tabs (i.e. to each configuration) only to set one or two settings.

What I've gathered from the discussion so far, is that per build configuration of build events is required. I think it would be best to configure this from the project that contains these build configurations (i.e. where the room is currently set).

Would it be fair to make the assumption that all build configurations of a project will use the same room?

It would then probably work best if all the build configurations are listed on the project page as a dropdown, displaying the events for the selected build configuration.

I also need to keep in mind hierarchical configurations (projects with subprojects). I think this is where it gets tricky. The room configuration allows one to use the room from the parent, another room, or none.

What would the case for build configurations be? Should there be a project default which build configurations use by default, and then the specific settings for a build configuration overrides the default, or is the default just the global default (i.e. as configured on the global administration page)? Or, should there be no such inheritance in this case?

[yanns]

I would say:

• the global configuration is the default one
• per project (it can be a deep sub project), we can override all settings

[jshumaker-accusoft]

I'd want to be able to override at the project level all of the options from the "Build Events Configuration" section that is in the global settings. Defaults for all should be parent project, with defaults if nothing is set even at top level, to be the global settings.

I'm not as interested in a per-configuration configuration, but if there was one then I'd see it inheriting the project configuration first, then having the option to override it there.

We're a medium sized company with a lot of project teams and for different projects different settings make sense. Some want to know when builds start, others when they complete, others only when they fail. We've largely migrated to using tcWebHooks instead so we can accomplish this. It'd however be easier to manage via this plugin instead. Especially customizing the message based upon success/failure.

[parautenbach]

I appreciate your feedback. I would like to mention that I've built this in my spare time, for free, and not as someone associated with Jetbrains or Atlassian. We use the plugin at my current company, and for our purposes it is feature complete. That said, I have complete understanding for your situation. Kindly take note that this is an open project, and I'd like to invite you to contribute. I would gladly accept pull requests. Building what you're requesting isn't hard, but it is a lot of work, and will require a lot of testing, as one can see from other settings that are already implemented this way. Would you be keen to contribute? I can't promise, but when I have some time, I will work on this, but it may not be soon.

[jshumaker-accusoft]

I'd love to assist if i can find some time to work on it myself, and I understand you may not be able to get to it any time soon, or ever. Definitely some nice functionality to it as-is and if we were a smaller or more focused company it'd definitely work perfectly for us.

My java skills are quite poor, so if i do get to this unfortunately it'd probably require significant review, but maybe i'll surprise myself.

[vivian-ho]

Here are the build configurations we have:

1. Build every GitHub pull request to make sure it doesn't break the build
2. Deploy a build (onto several machines)
3. Run integration test

We only want to send HipChat messages to our build deployment room for build config 2), and maybe 3) and don't want to pollute the room with results from build config 1).

So a per build configuration would be a big plus.

[vivian-ho]

Oh well maybe we can convert build configs into projects for now.

[acvanzant]

Bumping this as we are just getting HipChat and are also disappointed in the lack of per Build Config settings. We are, sadly, not very consistent between projects and teams, how we use teamcity, hipchat or even branches and source control.

[nachtfisch]

+1 great job overall for the plugin:)