On 11/16/2016 10:01 AM, Fabien Boucher wrote: > Hi, > > What do you think about planning a story for the next sprint including: > - the merge of the patches you worked on Yes please, though they are pretty trivial and could be merge as regular "storyless" contribution...
> - extending the documentation of the feature Indeed > - a functional tests ? This test is quite expensive and there isn't much value running that in the gate. A test like the nodepool "health-check" would be preferable. > > Le 16/11/2016 à 08:52, Tristan Cacqueray a écrit : >> Hello folks, >> >> doing a 3rd party CI simulation is quite a tedious process, here is >> recollection of my fixes/notes: >> >> >> * Deploys two stack, preferably using the 'minimal' template[0], called >> upstream.com and downstream.com >> >> >> * Adds upstream.com ip address to the static_hostnames[1] setting on >> downstream deployment, e.g. in sfconfig.yaml: >> >> network: >> static_hostnames: >> - "46.231.133.208 upstream.com" > > Why is this needed ? in case the upstream cannot be resolved. It's needed because https access to gerrit (for zuul-cloner purpose) requires a DNS. And unfortunately /etc/hosts is managed by Ansible, thus we need a way to add a custom dns for the other SF. >> >> * Fetch and install upstream.com localCA[2]: >> >> downstream# curl -k https://upstream.com/localCA.pem > \ >> /etc/pki/ca-trust/source/anchors/upstreamCA.pem >> downstream# update-ca-trust > > Could this be automated when an additional gerrit connexion is configured > in sfconfig.yaml ? > Probably though it's really needed when one SF act as a third-party of another SF which is deployed with a self-signed certificate... >> >> * Enable downstream zuul to connect to upstream zuul[3] >> >> upstream# ./gerrit-set-ci-user.sh downstream-zuul \ >> "$DOWNSTREAM_KEY" [email protected] >> > > Ditto > Well this needs to happen on the "upstream" sf, not where the 3rd party CI configuration happen. I don't think all these steps need to be automatic, though an "health-check" type using an Ansible based integration test could easily do a test configuration. >> * Check downstream zuul can connect to upstream >> downstream# sudo -u zuul ssh -p 29418 [email protected] >> >> >> * Adds upstream to downstream sfconfig.yaml: >> >> gerrit_connections: >> - name: "upstream" >> hostname: upstream.com >> puburl: https://upstream.com/r/ >> username: downstream-zuul >> >> >> * Check downstream zuul is connected >> >> downstream# # netstat -n | grep 29418 >> tcp 0 0 192.168.240.5:48212 192.168.240.5:29418 >> ESTABLISHED >> tcp 0 0 192.168.240.5:39902 46.231.133.208:29418 >> ESTABLISHED >> >> >> * Add a new job, e.g. config/jobs/tp.yaml: >> >> - builder: >> name: prepare-upstream-workspace >> builders: >> - shell: | >> export ZUUL_BRANCH=${ZUUL_BRANCH:-master} >> export ZUUL_REF=${ZUUL_REF:-None} >> [ "$ZUUL_REF" = "master" ] && ZUUL_REF=None >> echo "Clean workspace" >> rm -Rf ./* >> echo "Clone $ZUUL_PROJECT" >> zuul-cloner https://upstream.com/r $ZUUL_PROJECT >> >> - job: >> name: 'upstream-check' >> defaults: global >> builders: >> - prepare-upstream-workspace >> - shell: cd $ZUUL_PROJECT && ./run_tests.sh >> triggers: >> - zuul >> node: 'master' >> >> * Add a new zuul configuration, e.g. config/zuul/tp.yaml: >> >> pipelines: >> - name: 3rd-party-check >> manager: IndependentPipelineManager >> source: upstream >> trigger: >> upstream: >> - event: patchset-created >> - event: comment-added >> projects: >> - name: upstream/sandbox >> 3rd-party-check: >> - upstream-check >> >> >> * Create project upstream and submit a patch >> >> >> * Watch zuul magic: >> >> downstream# tail -f /var/log/zuul/{debug,merger-debug}.log >> >> That's it, new change upstream should trigger the zuul-demo-unit-tests >> downstream. >> >> Regards, >> -Tristan >> >> [0]: https://softwarefactory-project.io/r/5322 >> [1]: https://softwarefactory-project.io/r/5413 >> [2]: https://softwarefactory-project.io/r/5412 >> [3]: https://softwarefactory-project.io/r/5416 >> >> >> >> _______________________________________________ >> Softwarefactory-dev mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/softwarefactory-dev >> > > > > _______________________________________________ > Softwarefactory-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/softwarefactory-dev >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Softwarefactory-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/softwarefactory-dev
