[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: |
|
||||||||
| Sprint: | |||||||||
| Development Team: | FOLIO DevOps | ||||||||
| Description |
|
See
Integration options to add:
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 ] |
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.
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 ] |
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
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. |