[FOLIO-3023] better CI/GitHub integration Created: 18/Feb/21  Updated: 30/Mar/21

Status: Open
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Task Priority: P3
Reporter: Jakub Skoczen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to FOLIO-2885 SPIKE: consider improvements to the r... Closed
Sprint:
Development Team: FOLIO DevOps

 Description   

See FOLIO-2885 Closed for context.

Integration options to add:

  • automatically build and publish release artefacts when a version tag (vX.Y.Z) appears  in the repo
  • automatically biuld and publish pre-release artefacts when a change occurs on the release branch (bX.Y). Tag the artefact with a prerelease suffix (e.g  vX.Y.Z-pre1)

Either Jenkins or GitHub Actions should be used for the integration. 



 Comments   
Comment by Jakub Skoczen [ 18/Feb/21 ]

John Malconian Zak Burke Guys, please provide feedback on this ticket.

Comment by Zak Burke [ 18/Feb/21 ]

automatically build and publish release artefacts when a version tag (vX.Y.Z) appears in the repo

Sounds great to me, but I would like to make sure other folks agree before implementing this just in case there are any concerns. I don't know why there would be since all we are doing is automating the existing process, not changing it, but you never know. I will put it on the agenda at #stripes-architecture next week.

automatically build and publish pre-release artefacts when a change occurs on the release branch (bX.Y). Tag the artefact with a prerelease suffix (e.g vX.Y.Z-pre1)

I don't know about this one. The amount of work I do on release branches is minimal, and even if I'm picking a bunch of commits onto a release branch, I'm generally less likely to push each one to GitHub than to pick them all over, run tests locally, then make the release commit to set the version correctly, then tag, and finally git push all that work at once.

IOW, I would be unlikely to use – or ever even see – those -pre.BUILD_NO builds.

TBH, I'm more inclined to investigate how to change our development workflow so we can use -pre.BUILD_NO in place of the inflated patch versions we currently publish to npm-folioci, but that has broader implications that we need to suss out first.

Comment by John Malconian [ 18/Feb/21 ]

Regarding automatic build of tags,  this looks like the way to go for Jenkins.  https://github.com/jenkinsci/basic-branch-build-strategies-plugin/blob/master/docs/user.adoc#tags

 

Regarding building pre-release artifacts,  I'm hesitant about producing yet another class of build artifacts, but some questions/issues would be:

1.  Where would these artifacts be deployed?   Would they be mixed in with snapshot builds?  A whole new reference environment?  

2.  How does the versioning of these artifacts affect Okapi's ability to detect the latest versions of artifacts when mixed with snapshot and release artifacts.  

3.  Where would these artifacts be stored?  Separate repositories or same repositories as snapshot artifacts?  

 

I almost believe that if publish pre-release artifacts from release branches, then maybe we should NOT publish "snapshot" artifacts from master.   Maybe "snapshot" artifacts are built from pre-release branches instead. 

Comment by John Malconian [ 18/Feb/21 ]

Another question on automatically building tags:  What happens if a tagged build fails?  Will developers notice if their release build fails for any reason?   Who is responsible for ensuring a successful artifact is produced? 

Comment by Zak Burke [ 19/Feb/21 ]

Another question on automatically building tags: What happens if a tagged build fails? Will developers notice if their release build fails for any reason? Who is responsible for ensuring a successful artifact is produced?

This is not any different at present. I guess right now, Jenkins has better tools to notify the person who started the build if it fails?

I have cron jobs that look for failed builds on master branches of many UI repos. On the one hand, it feels kind of upside down (I'd rather be able to subscribe to branch builds in Jenkins and have it notify me when they fail rather than having to poll and ask, "Did the last build fail?") but, whatever. If we had

  1. a machine readable copy of the wiki's module-responsibility matrix
  2. a specific branch on which all release builds were tagged, e.g. release

then it would be easy to use a similar cron job to email/slack the "right" people when builds they are responsible for fail, even (especially!) if they are not the people who triggered these builds.

Comment by Jakub Skoczen [ 16/Mar/21 ]

We decided to put this on hold until GitHub Actions are in a more widespread use.

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