ci: add simple build test workflow

[MichaIng]

as well as a dependabot config to update used actions in workflows.

When building from a fork, tags may not exist. Try to obtain latest tag from upstream via GitHub API in this case. Exit early if this fails as well, as DEB packages strictly require their version to start with an integer. For debugging reasons, error output is unmuted.

As we talked about it, as a start 🙂.

I took the if: logic of the workflow from our repos:

• I personally want tests to run transparently on PR updates from fork branches, as well as on pushes to fork branches, which do not have a related PR.
• Adding both triggers however leads to duplicates, when opening a PR with a branch from the own repo: tests run for the push, as well as for the PR update.
• Using the push trigger only, runs the test on the fork repo (if it is from a fork), hence results do not show up and cannot be handled in the PR on the upstream/base repo.
• Only solution I found is to add both triggers, but add this condition so that the PR-triggered tests run only, if the PR is from a fork.
• As result:
  • the push triggered test runs always, hence on the own repo, if the branch is on the own repo, else on the fork. So people who work on their fork can also check and rerun tests on their own repo, like they run on my fork here now on every push: https://github.com/MichaIng/raspotify/actions
  • the PR triggered test runs only, if the PR has a fork as head. So test results can be seen and handled right within the PR. I am actually not sure if this happens as well, when the PR itself adds the test, hence if it does not exist on the base yet. So it might not be shown right here. Let's see ...
    EDIT: Oh nice, they do show up right here. So yeah, these are the "pull_request" triggered tests, intended to run only if the PR is from a fork, like in this case. When you open an internal PR, or push to any branch on your repo, a set of "push" triggered tests is supposed to run instead. And once the PR has been merged into the repos main branch, you can also manually trigger them for any branch from the actions panel, as I added the "workflow_dispatch" trigger as well: https://github.com/dtcooper/raspotify/actions

[kimtore]

How about starting the whole subroutine with git fetch --tags origin instead? This will ensure tags locally and not trigger a HTTP request to GitHub.

[MichaIng]

The problem is not that tags are locally missing, but that the fork repo in fact does not have any tags, also not online. I could rephrase the log to "local/origin", to make that clear. It just makes sense for anyone who contributes to the project, forking the repo to make an edit, then open a PR upstream: forks do not contain any tags, unless they are created at the fork.

[kimtore]

I see. But is it really necessary to have the correct tag output in the build unless it is a release build? What is the value of having this tag?

[MichaIng]

The tags are used for the version string or the DEB packages. Originally, without a tag, "unknown" is used, which is no valid version for DEB, as it strictly requires version strings to start with an integer. Of course we could "echo 1" or so, but I see no reason for DEB packages built on forks to have no proper version string, which compares well to upstream/distro/installed versions of the package, even if it is used for testing purposes only.

[kimtore]

Very well, however I fear it will potentially silently ignore tags from a (faulty) local copy.
I want the checked out copy to be the source of truth for the version tag, not the upstream.

[kimtore]

Hi again.
How about a guard before L163 that checks whether the locally checked-out copy's origin is dtcooper/raspotify? This way we can have the best of both worlds.

[MichaIng]

Sounds good. I'll implement this in a few hours.

[MichaIng]

Not so trivial to know whether the local repo is supposed to be dtcooper/raspotify or not. Git itself has no concept for owner or repo name, this is all a GitHub-only thing. Best I could find is checking the origin remote URL, which is by default matching the repository that was originally cloned. GitHub allows some variations for this URL, and even that they are all redirected to a canonical, git remote still returns the variant that was entered when cloning the repo.

... okay and it does not work for the pull request triggered runs: On my fork, the push triggered builds were successful, but here not. Reason is that the origin indeed is https://github.com/dtcooper/raspotify, and the "branch"/"ref" reflects the code from my fork instead. So we would need to check the ref as well, whether it is a pull request (should be possible to see from the name scheme). But this is becoming quite complicated and error-prone/not failsafe, worth the hassle?

EDIT: If this requires some more thoughts, we can leave the build script untouched for now, and only replace the "unknown" with e.g. a static "0.1" from within the workflow, for tests to succeed as well on forks. In the workflow we can derive from variables, who the repo/head owner is, hence whether we can count on tags or not. I mean this PR was originally about adding a build test, not about making the build script itself compatible with forks. That can be done any time later, if there is a demand.

[kimtore]

But this is becoming quite complicated and error-prone/not failsafe, worth the hassle?

Screw it then -- it was worth a shot, but I prefer simplicity.

I'll try merging this PR as-is and see where that gets us :)

In the future I want to implement nightly builds, i.e. the latest commit on main should produce a GitHub pre-release where users always can download the latest debs, for testing.

[kimtore]

I'll merge through the GitHub clickops after you revert that last commit then.

[MichaIng]

GitHub just made the ARM runners available for open source repositories: https://github.blog/changelog/2025-01-16-linux-arm64-hosted-runners-now-available-for-free-in-public-repositories-public-preview/

I was wondering whether there is a benefit to use those for ARM builds, but since we do cross-compiling and no emulation, at least no speedup.