You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Jan Lehnardt <ja...@apache.org> on 2021/11/26 10:23:24 UTC
GH Workflows
Hey all,
we recently received a nice contribution (SpiderMonkey 91 support) as a community contribution:
https://github.com/apache/couchdb/pull/3842/files
It includes a GH workflow that includes building said SM version to prove that it works, which is very nice.
We currently don’t really test a matrix of SM versions, and we probably don’t want to build sm from source on each CI run.
My question to you is how you think we should handle this?
Best
Jan
—
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/
24/7 Observation for your CouchDB Instances:
https://opservatory.app
Re: GH Workflows
Posted by Nick Vatamaniuc <va...@gmail.com>.
Option 1 sounds good - picking a variety of OS and packaged SM
versions. For 91 we may have to add a new OS into the mix - Fedora 35.
I saw it was the only distro packaging mozjs91
(https://pkgs.org/search/?q=mozjs91)
-Nick
On Fri, Nov 26, 2021 at 12:38 PM Adam Kocoloski <ko...@apache.org> wrote:
>
> I see a couple of possible options:
>
> 1) Implicitly test against a matrix of SM versions because we use the packages that are shipped with each supported OS in the CI matrix, e.g. CentOS8 -> SM60, Ubuntu 20.04 -> SM68, Debian 11 -> SM78 (that last one’s not in Jenkins CI yet I think). In this model we only add official support for new SM versions when they show up in a supported distro.
>
> 2) Reinvigorate the couchdb-pkg machinery we use to generate SM 1.8.5 packages to publish .debs for all supported SM versions, then add a new matrix build to verify support.
>
> I guess the key question is whether we expect users to continue to depend on distro packages for their actual production installation. If so, then I’m not sure a separate matrix offers a great return on investment. We could easily end up in a situation where CouchDB works with the SM package that we built for CI, but not the one the distro maintainers ended up publishing. That said, if someone wants to do the work, great!
>
> An option to trigger a manual integration run against a specific version of SM also seems like an OK compromise to me.
>
> Adam
>
> > On Nov 26, 2021, at 5:23 AM, Jan Lehnardt <ja...@apache.org> wrote:
> >
> > Hey all,
> >
> > we recently received a nice contribution (SpiderMonkey 91 support) as a community contribution:
> >
> > https://github.com/apache/couchdb/pull/3842/files
> >
> > It includes a GH workflow that includes building said SM version to prove that it works, which is very nice.
> >
> > We currently don’t really test a matrix of SM versions, and we probably don’t want to build sm from source on each CI run.
> >
> > My question to you is how you think we should handle this?
> >
> > Best
> > Jan
> > —
> > Professional Support for Apache CouchDB:
> > https://neighbourhood.ie/couchdb-support/
> >
> > 24/7 Observation for your CouchDB Instances:
> > https://opservatory.app
> >
>
Re: GH Workflows
Posted by Adam Kocoloski <ko...@apache.org>.
I see a couple of possible options:
1) Implicitly test against a matrix of SM versions because we use the packages that are shipped with each supported OS in the CI matrix, e.g. CentOS8 -> SM60, Ubuntu 20.04 -> SM68, Debian 11 -> SM78 (that last one’s not in Jenkins CI yet I think). In this model we only add official support for new SM versions when they show up in a supported distro.
2) Reinvigorate the couchdb-pkg machinery we use to generate SM 1.8.5 packages to publish .debs for all supported SM versions, then add a new matrix build to verify support.
I guess the key question is whether we expect users to continue to depend on distro packages for their actual production installation. If so, then I’m not sure a separate matrix offers a great return on investment. We could easily end up in a situation where CouchDB works with the SM package that we built for CI, but not the one the distro maintainers ended up publishing. That said, if someone wants to do the work, great!
An option to trigger a manual integration run against a specific version of SM also seems like an OK compromise to me.
Adam
> On Nov 26, 2021, at 5:23 AM, Jan Lehnardt <ja...@apache.org> wrote:
>
> Hey all,
>
> we recently received a nice contribution (SpiderMonkey 91 support) as a community contribution:
>
> https://github.com/apache/couchdb/pull/3842/files
>
> It includes a GH workflow that includes building said SM version to prove that it works, which is very nice.
>
> We currently don’t really test a matrix of SM versions, and we probably don’t want to build sm from source on each CI run.
>
> My question to you is how you think we should handle this?
>
> Best
> Jan
> —
> Professional Support for Apache CouchDB:
> https://neighbourhood.ie/couchdb-support/
>
> 24/7 Observation for your CouchDB Instances:
> https://opservatory.app
>