Hi Sean/Fabio - I���m still mulling over which direction to jump.  When experimenting with PharoLambda and a minimal image it was all very custom and so I just used GitLab ���natively��� - and as you have noted - Gitlab has got a lot of built in CI stuff.

Now my need has expanded to something a bit more normal - I was a bit caught out that the above didn���t just work the same. As its turned out - what has been the hiccup has been not having a good stable Linux image to build on (I���ve now learned Docker to sort that bit out - and really must +++ the need to have some pharo.org docker containers just sitting there for people to use).

The other issue has been what you have said - in a clean build environment you don���t have ssh keys normally defined and and the use of Iceberg and projects using github:// (which needs them by default) causes quite a lot of pain (even if they aren���t private repos).

I mention this as Herby spotted it a while ago as he doesn���t use GitHub - however he also spotted a solution that I don���t think you are aware of (judging from your gitlab project) - in your preload script add the following:

Iceberg 
    enableMetacelloIntegration: true;
    remoteTypeSelector: #httpsUrl.

This was the piece I was missing - and now my project is loading fine (in its fresh docker environment). 

You of course probably still have Private repos and in that case I think you still need the ssh keys sorted - but for a more general case I don���t think its needed.

This long path (which has usefully solidified lots of things for me) still leaves me unsure as to whether I personally need SmalltalkCI for simple single vendor projects (as when used in GitLab - its not really doing any CI - it seems more useful for muli-dialect building I think). Maybe you guys might set me straight on this��� the reality is all you are really plugging into Gitlab is:

pharo Pharo.image --no-default-preferences --save --quit st loadProject.st \
    "{'$PROJECT_NAME'. '$PROJECT_API_KEY'}" 2>&1 | tee LoadProject.log

And if you are also doing some testing a second invocation (ideally in a separate build stage) of:

pharo Pharo.image --no-default-preferences --save --quit st testProject.st \
    "{'$PROJECT_NAME'. '$PROJECT_API_KEY'}" 2>&1 | tee TestProject.log

And with a good docker image it seems pretty straight forward. Possibly there are components in SmalltalkCI that could be extracted - maybe to interpret test results? Or I am wondering if its useful to pump stats into something like DataDog to track image size and test run times etc?

I���m still interested in both your thoughts though - and by no means is this a citicism of SmalltalkCI or Gitlab-Smalltalk-CI - both of which help the community (and me) immensely through providing great examples and knowledgable people in this stuff.

Tim


On 16 May 2018, at 02:50, Sean P. DeNigris <sean@clipperadams.com> wrote:

Tim Mackinnon wrote
Have you written anything else up about it - or is this the ���user manual���
for now?

The latter :) It was an itch I scratched because GL offers unlimited private
projects and significant CI build time for free and then shared just in case
others were struggling with the same thing, but I'm happy to answer
questions and add to the docs.


Tim Mackinnon wrote
Presumable a lot of the below could go in the readme.md for the project
itself.

Already done!


Tim Mackinnon wrote
So to get started with it

In your project's root folder, if you copy `.gitlab-ci.yml` verbatim and
modify `.smalltalk.ston` as needed, it should start building your project on
top of Pharo 6 & 7 on 32-bit Ubuntu LTS. The Smalltalk image versions can be
changed to anything accepted by smalltalkCI, and I think to support other
OS'es we'd just need to build alternate Docker images [1]. You would only
need to fork gitlab-smalltalk-ci if you want to modify the internals of the
library itself. If you just want to customize any of the scripts in
./scripts [2] on a per-project basis, you can just save overridden copies in
./scripts in your project. The library will not overwrite existing script
files in that location.

FYI I did not explore deploy steps yet. I was actually waiting to develop
further because the next thing I want is separate build and test steps so
one can immediately know whether the installation or testing failed, and it
seemed that might be added to smalltalkCI in the near future.

1. There is also a related library which enables you to generate docker
files from Pharo. See
https://github.com/seandenigris/smalltalkCI/tree/docker/repository/SmalltalkCI-Docker.package
2. https://gitlab.com/SeanDeNigris/gitlab-smalltalk-ci/tree/master/scripts



-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html