Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extensions using Jenkins library #55

Closed
tedinski opened this issue Jul 27, 2017 · 5 comments
Closed

Extensions using Jenkins library #55

tedinski opened this issue Jul 27, 2017 · 5 comments

Comments

@tedinski
Copy link
Member

Right now we have duplicated Jenkinsfiles in every extension. This makes it difficult to fix up the build & test process for each extension all at once.

Jenkins pipelines support "shared libraries" : https://jenkins.io/doc/book/pipeline/shared-libraries/

If I understand this documentation correctly, we could do this:

Create a melt-jenkins repo, with the organization suggested in that link (probably just using the vars/ approach).

Then we should be able to import that library by writing:

@Library('github.com/melt-umn/melt-jenkins@master') _

Inside each extension. I suspect we should then have each extension have a Jenkinsfile that looks like this:

@Library('github.com/melt-umn/melt-jenkins@master') _

properties(ablecExtensionDefaultProperties)

buildAbleCExtension("ableC-condition-tables")

I expect our library would have:

  • Some default values: ablecExtensionDefaultProperties and silverDefaultProperties for ableC extensions and Silver projects generally. So we don't have to repeat their descriptions and the like.
  • buildAbleCExtension written all in one place
  • notifyBuild doesn't need repeating everywhere
  • Maybe other helpers / refactoring as needed. :) I'd like to use some of these things in refactoring the AbleC Jenkinsfile itself, and as part of writing a Jenkinsfile for Silver (finally) too.

Thoughts?

@krame505
Copy link
Member

This would be useful, for sure. Updating these Jenkinsfiles can get ugly...
Another note if we are going to be refactoring these: Some extensions depend on others, so changes in one could cause others to fail. We may want to have extensions that are depended on by others build some of these dependant extensions, similar to how the ableC Jenkinsfile builds other extensions as well.

@ericvanwyk
Copy link
Contributor

This sounds good to me. @tedinski do you want to get started on this?

@tedinski
Copy link
Member Author

tedinski commented Jul 31, 2017 via email

@tedinski
Copy link
Member Author

I've posted a start. The functions can be found here:

https://github.com/melt-umn/jenkins-lib/blob/master/vars/melt.groovy

The repo otherwise just a README at the moment, basically.

I haven't started using/testing these yet. Next week. I thought I'd just invite any public comments on what I have there so far. (I'm in the middle of trying to figure out how to make doesJobExist actually work, without just causing security exceptions, but other than that, there's a few things there.)

My plan right now is to get copper, silver and ablec using these. Then add maybe a ablec.groovy next to melt.groovy, and start factoring out what AbleC extensions do there, starting with just skeleton.

@tedinski
Copy link
Member Author

tedinski commented Feb 8, 2018

Done. All the extensions are using a shared library now. Even ableC_sample_projects re-uses a lot of code.

@tedinski tedinski closed this as completed Feb 8, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants