Build Sailfish OS application using GitHub Actions or GitLab CI

Applications
41

yes, you are correct. I seem to have moved to submodules at some point. I will plead dementia.

1 Like
42

I observed (for many years, i.e. many hundred CI-runs) that the time to download an image with its additional layers from DockerHub uses between 30% and 60% of the overall runtime of a CI-job at GitHub. Hence “Yes”, also publishing the coderus/github-sfos-build@XXXX and coderus/sailfishos-platform-sdk Docker images at GitHub would significantly speed up compile runs using these images. This does matter, because I let a CI-test run for each commit to a branch for which a PR to the master / main branch exists: Very often I end up waiting for the CI-test to finish before I merge such a PR.

GitHub provides a nice how-to / documentation on how to use GitHub’s Docker “registry”, including how to upload Docker images in an automated manner:


P.S.:

I dont like github actions ci, i like how gitlab ci works.

But almost all people primarily host and develop their software at GitHub, not at GitLab, or a Gitlab- or Forgejo- (e.g. Codeberg) -instance. Consequently your Docker images are by far most often and foremost used for CI-workflows at GitHub.
:confused:

43

And, as you guessed, that does build. It does not create a release, but it does build. I was being hopeful that it would also produce a release :slight_smile:

44

For the sake of completeness and to round off @coderus brief version above, this is a fully functional version that makes a github release and pushes the noarch rpm to that tagged release.

name: Github CI build

on:
  push:
    tags:
      - 'v*'
  pull_request:
    branches:
      - main
env:
  RELEASE: 5.0.0.43

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v4
      with:
        submodules: true

    - name: Prepare
      run: mkdir output

    - name: Build i486
      id: build_i486
      uses: coderus/github-sfos-build@sfos5
      with:
        release: ${{ env.RELEASE }}
        arch: i486


    - name: Extract Version Name
      id: extract_name
      uses: actions/github-script@v4
      with:
        result-encoding: string
        script: |
          return context.payload.ref.replace(/refs\/tags\//, '');

    - name: Create a Release
      uses: softprops/action-gh-release@v1
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      with:
        name: ${{ steps.extract_name.outputs.result }}
        draft: false
        prerelease: false
        body: This release was autogenerated.
        files: 'RPMS/*.rpm'

Many thanks to @coderus @olf and @nephros … I think I got the original ‘extract name foo’ from @Rikudou_Sennin

2 Likes
45

it’s -i486 suffix, not -486.

1 Like
46

I do not comprehend why you set an ID, if you do not reference it anywhere?

I actually misguided @poetaster by telling him “If @coderus sets an ID here, it must be utilised somewhere [in GitHub workflow configuration YAML files or by GitHub actions], because that is an ID’s only purpose: Go find this place(s) to look for valid IDs defined by @coderus.”