| | 64 | 1. Check for [https://github.com/clarin-eric/SPF-SPs-metadata/pulls pull requests] in the CLARIN SPF metadata repository on GitHub. Emails are automatically sent by GitHub when a new pull request is created. |
| | 65 | 2. Make sure the pull request is as marked XSD valid by Travis CI. This is visible on the pull request page a couple of minutes after it is created. |
| | 66 | 3. Merge the pull request into the ''master'' branch and wait for Travis CI to generate the QA report visible in [https://clarin-eric.github.io/SPF-SPs-metadata/page/master_qa_report.html this table]. |
| | 67 | 4. Make sure the [https://clarin-eric.github.io/SPF-SPs-metadata/page/master_qa_report.html QA report] does not present any issue marked in red concerning the SP in question. Follow up with the committers (i.e., SP operators) on whether their submissions meet the [https://www.clarin.eu/content/guidelines-saml-metadata-about-your-sp guidelines] based on e.g. this sheet. |
| | 68 | 5. Create a pull request from the ''master'' to the ''production'' branch and merge it. |
| | 69 | 6. Cron job 1 running under the ''spf-cron'' user on the docker [https://gitlab.com/CLARIN-ERIC/docker-spf-md-pipelines clarin_spf_pipelines_1] image deployed at clarin-vps5, will update the SAML metadata batch at https://infra.clarin.eu/aai/md_about_spf_sps.xml. The CLARIN IdP will use this preproduction batch. |
| | 70 | 7. Organize login tests for every new SP using the CLARIN IdP. |
| | 71 | 8. Mark every new SP entity as production SP. Do this by adding the SP's entity ID to the list in the relevant [https://github.com/clarin-eric/pyFF_config/blob/master/job_b.fd job definition file] on GitHub. |
| | 72 | 9. Cron job 1 running under the ''spf-cron'' user on the docker [https://gitlab.com/CLARIN-ERIC/docker-spf-md-pipelines clarin_spf_pipelines_1] image deployed at clarin-vps5, will update the SAML metadata batches under https://infra.clarin.eu/aai/ (this time, including prod_md_about_spf_sps.xml). |
| | 73 | 10. To help everyone track new SPs and their registration statuses across identity federations, add the SPs to the [https://centres.clarin.eu/ Centre Registry]. |
| | 74 | 11. Cronjob 2 running under ''spf-cron'' user on the docker [https://gitlab.com/CLARIN-ERIC/docker-spf-md-pipelines clarin_spf_pipelines_1] image deployed at clarin-vps5, will use the information in the Centre Registry to analyze the SAML metadata batches under https://infra.clarin.eu/aai/ into useful pieces under https://infra.clarin.eu/aai/sps_at_identity_federations/. |
| | 75 | 12. DFN-AAI will pick up the mutations to [https://infra.clarin.eu/aai/prod_md_about_spf_sps.xml SAML metadata batch]. This will ensure that it is distributed throughout eduGAIN, and reviewed additionally by DFN-AAI. |
| | 76 | 13. Once DFN-AAI has picked up the new SP (and thus the SP is in eduGAIN) which you can determine via the [https://centres.clarin.eu/ Centre Registry], add the SP to further identity federations. Click on the country code columns in the above table for details on the identity federation-specific procedure. |
| | 77 | 14. Finally, check whether any new SP has been registered for multiple identity federations using [https://technical.edugain.org/entities this eduGAIN webapp] (i.e., a clash). In case a clash is found, request the SP operator to remove the registration with any federation other than the CLARIN SPF. |
