issue_42: ordering from most specific to least specific for team sett…

[guru-beach]

It seems to make more sense to have notifications go from most to least specific settings. We have many cases where application level checks have different pager_teams and the teams creating those checks don't have access to the node level configurations for pd_override settings. If no check team is configured, the node level config should be used, and if no node level config, the default api_key should be used.

Pull Request Checklist

Is this in reference to an existing issue?

General

• [ ] Update Changelog following the conventions laid out on Keep A Changelog

• [ ] Update README with any necessary configuration snippets

• [ ] Binstubs are created if needed

• [ ] RuboCop passes

• [ ] Existing tests pass

New Plugins

• [ ] Tests

• [ ] Add the plugin to the README

• [ ] Does it have a complete header as outlined here

Purpose

Known Compatablity Issues

[majormoses]

@guru-beach also can you please rebase? I see conflicts with master.

[majormoses]

@guru-beach can you rebase and improve the CHANGELOG message? if so I think I am good with merging it after confirming with a few users on potential impact and use cases that I don't have/use.

[guru-beach]

Hrm, I didn't update the test order, let me check into that.

[majormoses]

also it looks like you still need to rebase to fix conflicts.

[majormoses]

@guru-beach I still see conflicts do you need help rebasing? If you are ok with it I should be able to rebase your branch for you in your fork (assuming you allowed maintainers that when you opened the PR)

[guru-beach]

@majormoses I may need help with the rebase. Sorry. This is the first time I've tried to do this in github and between projects. I thought I did it properly, but apparently not.

I did allow edits from maintainers. Please let me know what steps you take so I can learn :)

[majormoses]

Cool if you have issues after trying I can fix it for you, that being said here are the basic instructions:

1. setup sensu repo as a remote git remote add upstream https://github.com/sensu-plugins/sensu-plugins-pagerduty.git
2. fetch changes: git fetch upstream
3. git rebase upstream/master
4. At this point your changes may include conflicts that require manual changes with your editor to choose whether you want your changes or upstreams changes or something entirely new. After you have fixed these in each file that has a conflict git status should allow you to check if there are any remaining. You can then do a git add $FILE_THAT_REQUIRED_CONFLICT_RESOLUTION and git rebase --continue to move to the next commit.
5. Once everything looks good locally you can then do a git push -f to force push as your changes locally vs the remote (on the git server) are different and need to be told don't try to resolve conflicts accept my new source of truth.

[majormoses]

I really need to write this up somewhere as it is a big obstacle to get people to contribute even outside the context of a public github project I have to somewhat regularly teach people to rebase.

[majormoses]

@guru-beach any progress on this or should I fix this up?

[majormoses]

@guru-beach I got around to rebasing this for you.

[majormoses]

released: https://rubygems.org/gems/sensu-plugins-pagerduty/versions/3.0.0

[guru-beach]

Sorry about that Ben, I've been on a road trip and wasn't staying up with my email. I've reviewed the changes and will keep the instructions for further use.

Thanks for the help!