On Wed, May 15, 2019 at 8:56 PM Kenneth Knowles <k...@apache.org> wrote:
> > > On Wed, May 15, 2019 at 11:21 AM Lukasz Cwik <lc...@google.com> wrote: > >> >> >> *From: *Michael Luckey <adude3...@gmail.com> >> *Date: *Tue, May 14, 2019 at 11:42 PM >> *To: * <dev@beam.apache.org> >> >> Hi, >>> >>> do we currently have a strategy on how to handle LTS releases in context >>> of incompatible changes on the build system? >>> >>> As far as I can see, the problem is (at least) twofold. >>> >>> 1. Incompatible changes on test-infra job definitions >>> >>> There might be changes in our groovy files which make it impossible to >>> build/test an old branch on Jenkins. How do we intend to handle this? Of >>> course, in that cases we could run seed job and reset Jenkins to >>> corresponding old state but this will impact or even stall development on >>> master. >>> >> >> There was a point in time where people were looking at migrating to >> Jenkins pipelines since the pipeline definitions are in the source >> repository. Any solution that moves configuration to be based upon the >> source repository and out of Jenkins would address/mitigate this issue. >> > > +1000 > > I've looked around for documentation that makes this as clear as > .travel.yml docs, but didn't find anything like that. If you know of any > good docs on this, please share. Or just scrape the knowledge from other > projects that are using it. > So something as Multibranch Pipeline [ https://jenkins.io/doc/book/pipeline/multibranch/ ] and some integration with GitHub [ https://plugins.jenkins.io/github-branch-source ]. Indeed, that seems to address this issue. Of course we would need to investigate in how that will align with our current workflow, but seems worth a look. > > >> 2. Incompatible changes on agents >>> >>> Even worse, we might introduce changes on the agents itself, which will >>> even render it impossible to successfully seed to that legacy state. Do we >>> have any option to revert to an old Jenkins agent setup in such cases? I am >>> currently unaware of a link from apache repo to Jenkins configuration state >>> to enable restauration of (old) agents? Is there such thing? >>> >>> Would it be possible/helpful to subdivide our Jenkins agent pool in some >>> way that seed job could be run only on a dedicated subgroup (which then >>> could be set to an old state)? If I recall correctly Yifan put a lot of >>> effort in migrating our agents to the newer jnlp approach. >>> and used a 'private' agent to do require testing. I assume this has >>> been a manual setup and is not automated to be useful in such cases? >>> >>> What do others think about this issue? Is it something to follow on or >>> more of a non issue? >>> >>> >> What about dockerizing the builds/tests, this would allow us to use older >> versions of the docker container for older branches. Contributors >> interested in Python development were looking at this for testing Py2 and >> Py3 at the same time[1]. >> > > I think docker-in-docker was the blocker. > Docker could certainly be of help here. And there have been some proposals how to address docker in docker. Maybe some sidecar approach [ https://jenkins.io/doc/book/pipeline/docker/ ] could also help. But for the time being, as far a I understand we do/should have some configuration files for Jenkins agent setup (some playbook). Are those under VCS? Could not find that in our beam repo. Is it possible to link with our releases or will it be sufficient to align by 'date', as change rate is probably rather low on that configuration? Who currently owns that setup? Best, michel > Kenn > > >> >> >>> Best, >>> >>> michel >>> >>> >>> >> 1: >> https://lists.apache.org/thread.html/4be0f687135b7c6778224dd76389a39f9ebf78a3cf9c4cb4e76ebb73@%3Cdev.beam.apache.org%3E >> >> >
