Release Deployment

[seandenigris]

How does one deploy build assets - like the image with the project loaded and corresponding VM - as part of a tagged release? I see that Pharo and SmalltalkCI itself both seem to do this, but I'm not sure where the magic happens and how to adapt for an arbitrary project. Any help would be appreciated.

[theseion]

That depends. You can do it automatically using a GitHub workflow, but in most cases, you just go to the GitHub releases page and create a new release. The Wizard will create a new tag you specify on the selected branch. Source code assets are generated automatically.

[theseion]

You can upload those manually when you create or edit a release. You can also publish assets via REST API / workflow. You can do this manually using the gh CLI, but there are actions you can use for this, e.g., https://github.com/marketplace/actions/gh-release. This action also gives you the option of attaching any artefacts you want.

[seandenigris]

Thank you for bearing with me as I'm a noob to this.

To make this more concrete, let's take a simple project - my Bookmark-Magic. I run the tests with smalltalkCI via (this GH action workflow](https://github.com/seandenigris/Bookmark-Magic/blob/master/.github/workflows/runTests.yaml) which IIRC I adapted from smalltalkCI itself. I'd like to attach the image and VM from that workflow to a release, possibly after repackaging into a zip file containing a folder with the structure GT expects.

Questions:

• Since I don't have these artifacts locally, how do I upload them?
• If one is using semantic versioning and also doing automatic releases on successful builds, how does the action no whether to increment minor/major/etc?

[theseion]

First, you need to decide how you want to release. Personally, I like to have a workflow that builds and creates a release when I push a tag. If we take that as an example, you basically download, build, assemble, package, then create the release, e.g., using the action I linked to above.

There are other ways of cutting releases, e.g., a development branch and a main branch and you create a release when you merge to main.

You can also do releases manually. For custom artefacts, what you need to do is store the artefacts from your build, then you can download them and upload them to your manually created release.

Another way: you can have a workflow that you trigger manually that builds and creates the release and that workflow can take input parameters, e.g., the version number.

My recommendation is to pick one that sounds good to you. You can always change your setup later. Once you've picked a strategy, we can talk about details.

[seandenigris]

I'm not attached to any particular way. Whatever is the simplest I guess to start. Are there any publicly available relevant examples I can use for inspiration. I expected to just look at the workflows from smalltalkCI, Pharo, GT, or whatever and be able to adapt them, but I didn't see anything related to release.

Not sure if I'm on the right track, but flopping around a bit, I got the release action available but it can't seem to "see" the files created by smalltalkCI.

smalltalkCI seems to place the files I'm interested in under /home/runner/.smalltalkCI/_builds:

But then I'm not sure how to access/refer to them from the release action.

The yaml says:

- name: Release
        uses: softprops/action-gh-release@v2
        if: startsWith(github.ref, 'refs/tags/')
        with:
          files: |
            *.image
            GlamorousToolkit*

But the action rep

orts:

[theseion]

That's probably an Ant like globbing pattern, e.g., **/*.image. But since you know where the image is: _builds/**/*.image.

[seandenigris]

Starting with the really nice instructions in the Pharo wiki, and making a few updates and enhancements, I have a phase 1 that I'm pretty happy with. It creates a "continuous" tagged release on each commit, with the image, changes, etc. zipped along with the release.

The real work is done in this shell script, which is called from the workflow here.

The build directory was /.smalltalkCI/_builds, and smalltalkCI renames image and changes to TravisCI.xyz, so I didn't need the wildcards at all, just cp "${build_folder}/TravisCI.image" "${project_name}.image"

This will get me started until I need semantic version releases, which shouldn't be too hard to modify. Thanks for the help!