Hi all,
As you all have noticed, I've been working to clean up common-lisp.net and
simplifying the administration process.
One of the things we have done is that we implemented a deployment pipeline
for the common-lisp.net main site using GitLab. It's been a great joy to
work with it so far and made deployment of new site content easier than
ever before.
*My proposal is to set up a GitLab CI based deployment pipeline* for *all
common-lisp.net <http://common-lisp.net> projects*. Meaning that I'm
proposing to import the current project pages (/project/*/public_html) into
GitLab repositories (<project-name>-site) with a gitlab-ci file which
causes the content to be published.
The approach above will mean simple import of the existing static content.
However, after import, the static output can be replaced by different input
and a static content generator, just like we did with the common-lisp.net
site.
Eager to hear your thoughts,
Erik.
All this talk about Jenkins and ASDF makes we wonder how much capacity is
available for CI on common-lisp.net.
I've been reluctant to run much except for the website generator on c-l.net.
This doesn't run very often so I don't think it's a burden. For my other
work, I use my own machines so as not to load c-l.net too much. (But CI
doesn't run very often on my own machines---maybe a couple times per month,
but tends to be very bursty depending on how much free time and motivation
I have.) I also didn't want to interfere with trac and gitlab for all the
projects on the site.
--
Ray
Dear Robert,
Are you sure you want to use Jenkins? Gitlab has built-in CI. And the CLF
has acquired Allegro CL licenses for a ASDF testing (graciously donated by
Franz Inc), and we have a to-do item to attempt the same for LispWorks. If
you’re willing, we would like to help set up ASDF testing pipelines as part
of common-lisp.net infrastructure.
If you have reasons of your own to set up a Jenkins setup and could use
access to Allegro and maybe Lispworks licenses for that purpose, please
reach out regarding that as well. I am not sure about any Jenkins
experience among clf or cl.net volunteers, however.
Please advise,
Dave
On Tue, Oct 13, 2020 at 11:06 PM Robert Goldman <rpgoldman(a)sift.info> wrote:
> Does anyone have expertise configuring Jenkins to run against a remote
> Gitlab install?
>
> If so, would you please reach out to me? I have *finally* restored some
> of my CI support for ASDF, but I don't know how to set up my Jenkins to run
> against merge requests on Gitlab (if that is even possible).
>
> I have a backlog of patches that I would like to get evaluated and merged,
> but could use some help with the automation.
>
> Thanks!
>
--
My Best,
Dave Cooper, david.cooper(a)gen.works
genworks.com, gendl.org
+1 248-330-2979
Hi,
The VM running common-lisp.net needs an O/S upgrade: the host is running
Debian Stretch which has gone EOL in July (but is receiving LTS updates for
specific components). Due to package compatibility issues, the upgrade
needs to go directly to Debian Bullseye (skipping Debian Buster).
We have a dependency problem with this upgrade: Debian Buster - which we'll
skip - was the last to support Python 2.7. We depend on Python 2.7 for the
following services: Trac, Mailman2.1, ViewVC and greylistd. All other
services either don't depend on Python, or have Python3 compatible versions
in Debian Bullseye. For Mailman2.1 we have a "simple" solution: migration
to Mailman3. Mailman3 is a totally new application coming from the
developers of Mailman2.1. For greylistd we will be able to either find an
alternative or we can stop greylisting entirely. For ViewVC, we hope to see
a release soonish which supports Python3 (and its inclusion in Debian); in
its repository, there's support for Python3 already, as is the required
Python3 support for the Subversion bindings.
This leaves us with just Trac which has been removed from Debian because of
its Python 2.7 dependency. Looking at its homepage, there doesn't seem to
be a Python3 compatible release yet. I really want to be running OS
packages, because those include (security) releases when issues are found
-- which saves the common-lisp.net manual monitoring of our dependencies.
These projects have Trac projects:
armedbear
bknr
cl-darcs
cl-irc
cl-markdown
cl-openid
cl-test-grid
cl-trane
cl-weblocks
clfswm
clo
cmucl
elephant
f2cl
fset
gsharp
isidorus
mcclim
movitz
nio
oct
ucw
usocket
So what's our next step? Do we go looking for a Trac alternative? Does
anybody have contacts with the Trac team and can consult with them about
their plans?
Regards,
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
