[FOLIO-2733] Rename mod-custom-fields to folio-custom-fields Created: 18/Aug/20  Updated: 02/Sep/20  Resolved: 02/Sep/20

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

Type: Task Priority: P3
Reporter: Pavlo Smahin Assignee: David Crossley
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Blocks
blocks MODCFIELDS-53 Rename mod-custom-fields Closed
Sprint: DevOps: Sprint 95, DevOps: Sprint 96
Development Team: FOLIO DevOps

 Description   

Since the current project https://github.com/folio-org/mod-custom-fields
will be used as a shared library and not as a separate module, it is needed to rename the module to

folio-custom-fields

The process to be followed is documented at https://dev.folio.org/guides/rename-module/



 Comments   
Comment by Jakub Skoczen [ 19/Aug/20 ]

Pavlo Smahin If the intention is to not use "mod-custom-fields" as a FOLIO module, why is there a ModuleDescriptor and LaunchDescriptor under /descriptors. And why do we publish them to the registry? Also, why do we need a stand-alone docker image for this project?

Comment by David Crossley [ 20/Aug/20 ]

Perhaps because they started this as a "mod-" module, and those would have been required.

As per the documented procedure, i will disable the Jenkinsfile during the renaming process. That will prevent it from deploying any more artifacts. Then after the developers have modified it to become a library, removing that mod-related stuff, then a new Jenkinsfile can be added.

Comment by David Crossley [ 20/Aug/20 ]

I did some other investigation.

The FOLIO Registry shows that the only other module that provides the "custom-fields" interface is "mod-users" (i.e. using interfaceType:multiple as specified).

The mod-custom-fields is not defined in folio-ansible or the platforms, so no adjustment is needed.

Comment by Pavlo Smahin [ 20/Aug/20 ]

Jakub Skoczen ModuleDescriptor is needed to copy it's content while integrating custom fields to other modules.

Comment by David Crossley [ 25/Aug/20 ]

The new repository is ready for you to do the next steps.

https://github.com/folio-org/folio-custom-fields

The old module is archived, and the code is copied with history.

As explained here:
https://dev.folio.org/guides/rename-module/#rename-git-configuration-source-docs
adjust all mentions of the old name, and remove other stuff that is now not needed.

I did already remove the Dockerfile.

When those changes are in place, then you can do this step:
https://dev.folio.org/guides/rename-module/#restore-jenkinsfile

I presume that the ModuleDescriptor now does not need to be deployed to the Registry.

When those steps are done, then i can finalise the branch protection Settings.

Comment by Pavlo Smahin [ 31/Aug/20 ]

David Crossley All mentions were adjusted and Jenkinsfile was restored.

Comment by David Crossley [ 01/Sep/20 ]

I have now re-established the "branch protection" Settings.

Comment by David Crossley [ 01/Sep/20 ]

As noted in earlier comments, because this is not being deployed as an actual module then the LaunchDescriptor is not needed.

Comment by David Crossley [ 01/Sep/20 ]

The Jenkinsfile currently has the setting "publishAPI = false", so API docs are not being generated and published. Yet RAML files are still being used.

Is that intended?

Comment by Pavlo Smahin [ 01/Sep/20 ]

Module descriptor and raml files are needed to copy it content while integrating custom field to other modules.

Comment by David Crossley [ 01/Sep/20 ]

Then the Jenkinsfile should have "publishAPI = true" so that people know the purpose and content for the endpoints.

Comment by Pavlo Smahin [ 01/Sep/20 ]

I agree. Fixed it.

Comment by David Crossley [ 01/Sep/20 ]

Great, thanks.

Regarding the other matter:
Yes i do understand that the local ModuleDescriptor is needed for copying content. However the LaunchDescriptor portion of the MD is not needed.

Comment by Pavlo Smahin [ 01/Sep/20 ]

Fixed this too.

Comment by David Crossley [ 02/Sep/20 ]

All is done now.

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