Add proper support for deployments

[fniephaus]

I've skimmed through the open issues and a significant number of them touch the deployments topic, so I am opening this one to group them in one and discuss deployments once more:

smalltalkCI should support deployments, but use cases may be different: there are different deployment targets (e.g. GitHub releases, Bintray, etc.) and different deployment artifacts (e.g. image/changes, error logs, ...).

I believe different deployment targets is similar to different code coverage services: each target platform usually has a tool/script for uploading specific artifacts, and it makes sense to give the user the ability to use those. However, the user must be able to find the artifacts.

If we look at other CI/CD systems, for example in OpenSmalltalkVM or in the Java world, build artifacts are often exposed in some sort of products output directory. I am proposing to add support for two directories accessible through environment variables in smalltalkCI:

• $SMALLTALK_CI_PRODUCTS is the directory containing all files (image/changes/maybe sources) ready for deployment
• $SMALLTALK_CI_DEBUG_DATA is the directory for images with persisted error objects / open debuggers, error logs / fuel files, other debug artifacts

The user could then point a deployment script at one or both of these directories to upload the corresponding files to their preferred platform.

The deployments topic is still open for discussion, so please feel free to comment if you have any suggestions, requirements, or feedback.

[fniephaus]

BTW: we might want to drop the Bintray integration (see https://github.com/hpi-swa/smalltalkCI/issues/146#issuecomment-223586660)

[gcotelli]

I think it's a good idea to handle it like we're now handling the coverage support. Just let the artifacts in some accessible place so the build can pick up the relevant files and use the platform deployment options. And +1 to also drop the bintray integration, just let the user choose what provider to use using the already available tooling.

[LinqLover]

Not sure whether this belongs into the same issue, but the "branding" could to be updated, too. For example, we are using smalltalkCI in Squeak by Example to generate PNG files for a book and everything works well so far. But from an aesthetical point of view, it could be considered confusing that smalltalkCI says things like "Testing project..." and "(264 tests passed)". Another example I encountered recently is TelegramClient where TestCase is subclassed for a TCTSarFileGenerator which, again, is not a test in its literal sense ...

Can we replace these terms with some build/test-agnostic terms? Or is this rather a question for SUnit only which originally provides the "test" vocabulary?

[fniephaus]

@LinqLover Well, smalltalkCI is designed to test projects by executing TestCases. If you use TestCase for something that is not a test, you are probably not using smalltalkCI for CI and the "branding" may be off. Such use cases are possible, and allowed, but I'm not sure smalltalkCI should try to cover every single one of them including very specific ones.

Regarding deployments: I try to implement the products directory idea next week. Also, I have an idea for naming image and changes files in the products directory: smalltalkCI could use the project/repo name as default, and users can change it via a #productName option in the ston configuration.

Last chance to add your thoughts! It's great to see blog posts like this one from @badetitou to show up, but I don't want any more users to rely on smalltalkCI internals (like directory names etc).

[LinqLover]

(To everyone searching for a fast solution for deploying images: As a cheap alternative, you could also refer to my new GitHub action LinqLover/create-image. Please pardon the self-promotion, but I am open to copying or moving any ideas of this action back into smalltalkCI!)