Adding ability to get changelogs for Multibranch Pipeline

[funtastix]

I notices my changelogs are empty for multibranch pipelines. This is due to the build job being neither an AbstractBuild nor AbstractProject, but a WorkflowJob. A simple fix to add this ability.

[mezpahlan]

Wow! This looks really good. Thank you for taking the time to make a PR.

I'm about to head into work now but will have a look at this when I get back and let you know if I have any questions.

Thanks again!

[funtastix]

I just realised im not checking the size of the list before accessing it. I will amend tomorrow.

[douglasknudsen]

interesting. I'm curious of an example use case. I get change-sets now without issue by reading currentBuild.changeSets in my pipeline regardless of hockey plugin, thus my curiosity. Not concerned of the change here, jsut wondering of use case

[funtastix]

@douglasknudsen how do you use currentBuild.changeSets with the HockeyApp plugin upload? My pipeline has a step like this:

hockeyApp applications: [
[
apiToken: 'api-key',
downloadAllowed: true,
filePath: 'sample.apk',
releaseNotesMethod: changelog(),
uploadMethod: appCreation(publicPage: true)
]
], debugMode: false, failGracefully: false

This fails to properly include the release notes without the patch. Works a charm with the change.

Note: I also needed to add baseUrl at the end for it to work.

[mezpahlan]

I'm happy to play around with both suggestions. The changes in this PR plus additional guidance on the wiki page.

@douglasknudsen could you let us know how your pipeline is working without these changes and I'll have a play around with both suggestions. Thanks.

[funtastix]

I've built a little sample repository to illustrate the case.

[douglasknudsen]

ah, so I use a little script function like the below with manual release notes. I see now that this PR make it super simple and smooth. Nice!!!

releaseNotesMethod:
[$class: 'ManualReleaseNotes',
isMarkdown: false,
releaseNotes: "SOME NOTES \n\n Changes: ${getChangeSet()} \n\n COMMIT:${GIT_COMMIT}"],

def getChangeSet() {
def changeLogSets = currentBuild.changeSets
def changes = ''
for (int i = 0; i < changeLogSets.size(); i++) {
def entries = changeLogSets[i].items
for (int j = 0; j < entries.length; j++) {
def entry = entries[j]
changes += "--> ${entry.msg} \n"
}
}
return changes.replaceAll( /'/, '')
}

[douglasknudsen]

I've built a little sample repository to illustrate the case.

sweet, this is much simpler.

[mezpahlan]

@funtastix Have you been able to run this with hpi:run? I'm getting a load of errors installing the plugin. How are you installing the modified plugin to be able to test it?

[funtastix]

@mezpahlan I was able to build and run when I committed the last change however I cannot any more. However, even the original unchanged version gives me errors now. Some javadoc API incompatibility. I'm a bit confused what has changed.

[mezpahlan]

@funtastix After I wrote that message I had a play with the dependencies. They're quite out of date and moving them from the test to compile scope seems to not be as straight forward as we thought.

I've got a copy of your branch locally that I'm trying some changes out in and it does seem to help bumping the version. I need to do a few more checks so if you don't mind waiting a bit I'll do those and report back here.

Are you happy for me to push directly to your branch so that this PR gets updated as we iterate?

[funtastix]

@mezpahlan I've given you access to both my repositories that I've created for this plugin.

[mezpahlan]

@funtastix Thanks! However as a maintainer for the repo you're trying to merge into Github lets me push commits to the branch that is being PR'd so I don't quite need all that access! 😺

I'm going to do a few more checks but it is all looking very promising!

[mezpahlan]

Hmm...... interesting. The verify / install checks pass locally but fail on the Jenkins CI server. Will investigate.

[mezpahlan]

Hi @funtastix I'm really sorry about this but the more I try and get it to work the further down the rabbit hole I go. My main issues at the moment are:

• If you simply build the plugin and deploy it, it seems to work (and really well). However it fails the build checks on the Jenkins server.
• I can't understand if this is due to a plugin that has moved from the test scope to the main scope or if it is a combination of the minimum version of Jenkins set for this plugin. The errors aren't extremely helpful :(

If you're building this yourself could you try mvn clean install and see what comes out. That's the point at which it fails on the Jenkins CI server.

[mezpahlan]

OK I think I have tracked down some part of the issue. The minimum version of Jenkins that appears to work given the updated dependencies seems to be 2.121. As of time of writing that is only 49% of the user base of this plugin so I don't want to update the minimum version in a point version.

This might take a little longer to integrate. I think I shouldn't have attempted to update all of the dependencies at once. 😢

I'll roll back my changes and then see if it works. I will update the dependencies separately. That's probably the best thing to do.

[funtastix]

@mezpahlan I've tried hpi:run this morning on another machine with the original 2 commits I made and there was no errors at all. mvn clean install runs without problems, too. However, on an older machine yesterday, I got errors.

[mezpahlan]

Yeah this is what I'm seeing as well. The only change I made now is a slight formatting change so it is essentially the same as your two commits.

What's the errors you see in the older machine? Can you paste it here?

[funtastix]

Unfortunately, I don't have access to that machine anymore. I remember it was related to API compatibility in a javadoc module.

[mezpahlan]

Thanks for checking. Do you remember roughly what the machine set up was? In particular the version of Java and Jenkins. I'll see if I can reproduce.

[AnneTheAgile]

is there such a thing in jenkins where you can feature flag code to a particular jenkins version? if so maybe that would help?

I am hoping my little PR gets put into a release soon :). In the meantime I' m looking for how to make my own copy, I swear I did it before with mvn etc.

[funtastix]

@mezpahlan it was a Windows 10 machine with openjdk-11+28 and maven 3.4.5.

The Jenkins version would have come from the dependencies.

[mezpahlan]

@funtastix Java 11 eh? Hmm..... possibly something to do with that. For now I'm going to read a bit more around this and try and understand if it is safe to release in its current form. I mostly think it is but I'll get some advice from the Jenkins Dev mailing list.

One of the suggestions from a previous PR was to bump the minimum version of Jenkins required for this plugin. At the moment it is 1.625.3 which is horribly out of date. I can bump it up and still serve the majority of users that have this plugin downloaded but if I do that I don't want to do it in a point release.

Let's target this for the 1.4.0 release (which should be the next one) and continue to investigate. Apologies this is taking longer to integrate that normal. I'd like to use this myself at work so these changes are very welcome!!

@AnneTheAgile I'm not sure if we can do that. Again I'll ask the Jenkins Dev mailing list for steps to move this forward. I've just released your changes as 1.3.3 which should be available in the update centre shortly (give it 8 hours to propagate).

[funtastix]

@mezpahlan yes 11. It was a spare machine with not much set up on it. I'm happy to use a patch version for now and wait for this to make a safe journey into a release. It's not part of a critical production pipeline so it's fine for me and saves me to write (copy) a release note script and then change again later.