[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: |
|
||||||||
| Sprint: | DevOps: Sprint 95, DevOps: Sprint 96 | ||||||||
| Development Team: | FOLIO DevOps | ||||||||
| Description |
|
Since the current project https://github.com/folio-org/mod-custom-fields 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: I did already remove the Dockerfile. When those changes are in place, then you can do this step: 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: |
| Comment by Pavlo Smahin [ 01/Sep/20 ] |
|
Fixed this too. |
| Comment by David Crossley [ 02/Sep/20 ] |
|
All is done now. |