Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Add symbols to extension points #50
The PR allows easier pipeline syntax instead of referring to the General Build Step and targetting the plugin class you can now do something similar to:
We are still targeting Jenkins 1.x hence the need to declare structs explicitly (if I understand correctly).
FYI: 94% of users running version 1.2.2 (released in early 2017) of your plugin, which are ~80% of all plugin installations, are on Jenkins 2.32.1 or newer based on anonymous usage stats ( http://stats.jenkins.io/pluginversions/hockeyapp.html ; which seems to include wrong versions, perhaps private builds, but only one install each, so insignificant)
Users who don't update Jenkins core don't update plugins either.
Thanks @daniel-beck. I want to do the following in the long run:
So it is on the plan but perhaps I should think again at the order I do these given the stats.
Jun 11, 2018
1 check passed
To add some context to this. The top level symbol name has not changed between the start and end of the PR. Only an internal descriptor for the releaseNotesMethod. To illustrate:
At start of PR:
hockeyApp applications: [[apiToken: 'secret-token', filePath: 'sample.apk', releaseNotesMethod: manualReleaseNotes(isMarkdown: true, releaseNotes: 'Bug fixes and minor updates'), uploadMethod: versionCreation('app-token')]], debugMode: false, failGracefully: false
At end of PR:
hockeyApp applications: [[apiToken: 'secret-token', filePath: 'sample.apk', releaseNotesMethod: manual(isMarkdown: true, releaseNotes: 'Bug fixes and minor updates'), uploadMethod: versionCreation('appt-token')]], debugMode: false, failGracefully: false
The top level symbol remains as
The last commit was purely cosmetic to remove the (in my opinion) redundant
Anyways, let me know if that makes a difference. Happy to revert it if it will cause collisions with other plugins.