Make tests built automatically

[gnott]

@giorgiosironi when you have time, could you please take a look at https://github.com/elifesciences/elife-pubmed-xml-generation to see what is required to enable automated library tests on Alfred? I think in the case of the new Crossref you hooked up a coveralls token? Thanks!

[gnott]

Any thoughts on this @giorgiosironi? I think we added ci tests for elife-article, and maybe we didn't add them for elife-crossref-xml-generation. Is this repo and the new Crossref one considered libraries in the ci environment?

[gnott]

Should I generate some coverage tokens and add any missing configuration files we added to (I think) elife-article project @giorgiosironi in order to reach the next step?

[giorgiosironi]

All libraries should be built with library-* pipelines, the main setup is to add a Jenkinsfile. It seems all the ones mentioned here now are build in Alfred:

• https://alfred.elifesciences.org/job/library-elife-crossref-xml-generation/
• https://alfred.elifesciences.org/job/library-elife-pubmed-xml-generation/
• https://alfred.elifesciences.org/job/library-elife-article/

Pull requests should behave in the same way, but built at https://alfred.elifesciences.org/job/pull-requests-projects/ when they are open (they get cleaned up afterwards).

[giorgiosironi]

All the coveralls token for these projects seem to be in place at https://github.com/elifesciences/builder-private/blob/master/pillar/elife-libraries.sls#L8-L12

[giorgiosironi]

Any bugs in the integration to sort out?

[gnott]

I think PR was perhaps built by Alfred, but it didn't show on the Github PR page, which is odd https://github.com/elifesciences/elife-pubmed-xml-generation/pull/9

I don't think there are any integrations required here yet, if I understand the question, because the new PubMed library hasn't been deployed into production yet.

I guess I could remove the travis-ci builds from PubMed as well as the other libraries, if I should just delete the travis-ci files, or should I just disable it from building on the travis-ci site instead by excluding the repo from what is enabled on travis-ci?

[giorgiosironi]

Testing with https://github.com/elifesciences/elife-pubmed-xml-generation/pull/10 since there could be some integration problem I didn't find before.

Deleting the files makes the repository easier to understand, so I would go for that.

[gnott]

I tried deleting the travis-ci related files, and I also disabled builds for the repo on the travis-ci site. It didn't seem to trigger any builds, so I went into the Github repo settings, and under Integrations & Services I added the Jenkins (GitHub plugin) and entered the webhook URL. That seems to work, so I deleted the travis-ci entry under Integrations & Services and now elife-pubmed-xml-generation is running on Alfred only.

[gnott]

I'm not sure I configured it correctly, PR https://github.com/elifesciences/elife-pubmed-xml-generation/pull/18 didn't trigger any Alfred build. @giorgiosironi perhaps if you could look at the repo settings and see what might be wrong about it?

[giorgiosironi]

We should need no set up on every single repository, since we use an organizational webhook (https://github.com/organizations/elifesciences/settings/hooks) that should send events for every repository. There is something wrong in the chain however, which I'll try to debug today.

[gnott]

It looks like PR elifesciences/elife-pubmed-xml-generation#18 had a build since yesterday. Should we remove the Jenkins integration I added to that repository if you have an organisation-level webhook?

[giorgiosironi]

Yes, repository level configuration should not be required (as we have too many repositories to configure). https://elifesciences.atlassian.net/browse/ELPP-3289 is the ongoing investigation for missing builds.

[gnott]

Thanks @giorgiosironi. I deleted the repo specific integration and I'll keep an eye on it as new code is merged.