[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
(builds everything because it's Alpine and no YAZ package for that)



 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 ]

Adam Dickmeiss

So what makes this a tooling decision? That mod-copycat that needs a shared object like libyaz5?

In the new technical decision process, two of the examples of decisions are

  • Introduction of new 3rd party dependencies, e.g. Spring, lombok, jooq, etc.
  • Introduction of tools or dependencies that require devOps to adjust build processes

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)

We could have probably avoided libyaz5 if we used a custom container for the Jenkins build.

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

It's tiny, though, compared to things like firefox, chrome, xvfb, that are also installed.

Agreed. Had we had this process in place for those, I would probably have asked the same question.

cc: Craig McNally Jakub Skoczen

Generated at Thu Feb 08 23:24:16 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.