[STRIPES-570] Document handling of forked repos in Stripes build Created: 15/Oct/18  Updated: 18/Nov/20  Resolved: 18/Nov/20

Status: Closed
Project: Stripes
Components: None
Affects versions: None
Fix versions: None

Type: Task Priority: P3
Reporter: Matthew Jones Assignee: Unassigned
Resolution: Done Votes: 0
Labels: stripes_documentation
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to FOLIO-1570 Identify release procedure for folio/... Closed
relates to STRIPES-568 Stripes documentation updates Closed
Sprint:
Development Team: Stripes Force

 Description   

As observed with folio/react-big-calendar and folio/react-githubish-mentions, forked third-party repos don't always play nice with our build process. This is because the forked repo likely has its own build and publish steps and should not be transpiled during a platform build of Stripes. (By default, all @folio-scoped modules will be transpiled using stripes-core's babel settings).

A brief set of recommendations to review prior to introducing a fork would help. Notably we should ask ourselves:

  • What artifacts need to be published?
  • What are the steps to generate them?

Then provide guidelines on:

  • Including a Jenkinsfile and using runScripts (or package.json prepublish?) to invoke such steps.
  • Add to the folio-scope exclusions when necessary


 Comments   
Comment by Matthew Jones [ 15/Oct/18 ]

After reviewing folio/react-githubish-mentions with John Malconian, it was noted that while this repo doesn't currently make use of "runScripts" to build, it does publish transpiled content. This is because a "prepublish" script exists to accomplish the task. The recommendation for runScripts over prepublish remains TBD.

Comment by John Coburn [ 17/Oct/18 ]

The repos/projects themselves each potentially have their own way of dealing with this that conforms to whatever their needs are. To keep the delta on forks to a minimum, it's not ideal to require many changes to that aspect of a project for it to be set up for CI. OTOH a single prepublish key in the package.json is a pretty small change - it would just be an experiment to run and be sure it worked. My Jenkins-fu is weak - John Malconian if necessary, could commands for publish also specified in a Jenkinsfile?

Comment by John Malconian [ 18/Oct/18 ]

if necessary, could commands for publish also specified in a Jenkinsfile?

Not sure I'm completely understanding the question. 'npm publish' is automatically run on the master branch or when the repo is git tagged and released. Outside of that, I don't think you want to run publish anywhere else. react-githubish-mentions currently has a prepublish script that invokes a 'build' script. This is totally fine, except that we probably want to invoke this build script in Jenkins for non-release/master branch builds as well. This can be accomplished by adding

runScripts = [ 'build', '']

to the Jenkinsfile.

Let me know if I'm missing something.

Comment by John Coburn [ 27/Oct/18 ]

Exactly what I was curious about, thanks! We've seen some diversity among the ways that third party repos handle their publishing task, but nothing that seems like runScripts won't fix. Some are set up as simple as a 'prepublish' key in the package.json, and various other keys set accordingly to that setup (files, main, module, etc) others have build (or similar) commands that run series of tasks necessary to generate their published files.

Comment by John Coburn [ 18/Nov/20 ]

Old story... the examples listed here are no longer in use. Closing!

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