[FOLIO-2925] Jenkins infrastructure for mod-copycat Created: 22/Dec/20 Updated: 08/Jan/21 Resolved: 30/Dec/20 |
|
| Status: | Closed |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Task | Priority: | P3 |
| Reporter: | Adam Dickmeiss | Assignee: | Ian Hardy |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Sprint: | DevOps: Sprint 104 |
| Development Team: | FOLIO DevOps |
| Description |
|
Jenkins infrastructure for mod-copycat 1. YAZ yaz is easy.. Exists as package already. So I guess it would be no big deal to just have it installed af part of the Jenkins image (or what it's called). 2 yaz4j.. Consists of yaz4j.jar + DLL/so .. (libyaz4j.so). yaz4j artifact needs to be published. Where? libyaz4j.so needs to be installed. It does NOT exist as a package anywhere. Could make a Debian package. yaz4j script could also be part of the mod-copycat Jenkins file somehow.. Ie a recipi for compilation and install. That would make a one time deal (JAR + SO together). Dockerfile for inspiration: https://github.com/folio-org/mod-copycat/blob/integrate-yaz4j/Dockerfile |
| Comments |
| Comment by Jakub Skoczen [ 22/Dec/20 ] |
|
Wayne Schneider Adam Dickmeiss Ian Hardy We have decided that Adam will make a deb package for yaz4j. This package must be added to the Jenkins build image so that mod-copycat can be built. mod-copycat runtime Docker image already includes yaz and yaz4j. |
| Comment by Ian Hardy [ 29/Dec/20 ] |
|
libyaz5 is installed on the folioci/jenkins-slave-all:java-11 image, which gets called when "buildNode = 'jenkins-agent-java11'" is specified in the Jenkinsfile. Adam Dickmeiss lmk if thats enought to get mod-copycat going. |
| Comment by Marc Johnson [ 30/Dec/20 ] |
|
Craig McNally Could this be an example of development tooling decisions? |
| Comment by Craig McNally [ 04/Jan/21 ] |
|
Marc Johnson certainly. It would be nice if we captured these sorts of things in the decision log. |
| Comment by Adam Dickmeiss [ 04/Jan/21 ] |
|
So what makes this a tooling decision? That mod-copycat that needs a shared object like libyaz5? We could have probably avoided libyaz5 if we used a custom container for the Jenkins build. It's tiny, though, compared to things like firefox, chrome, xvfb, that are also installed. |
| Comment by Marc Johnson [ 08/Jan/21 ] |
In the new technical decision process, two of the examples of decisions are
To me, this covers both of these, in the sense that libyaz5 is a new 3rd party dependency and it's introduction involved the DevOps team needing to make changes. As far as I can tell it also means that this module cannot be maintained by a developer using a mac (at least the native part of yaz4j is only supported on linux and windows)
To me, that would still have meant changes were needed to the Jenkins build processes by the DevOps folks and so would still be considered a technical design decision
Agreed. Had we had this process in place for those, I would probably have asked the same question. |