Need help with GitHub workflow setup

help
1

Just added auto-generated workflow file to this repository
but found build fails there with following error:

...
  The system library `glib-2.0` required by crate `glib-sys` was not found.
  The file `glib-2.0.pc` needs to be installed and the PKG_CONFIG_PATH environment variable must contain its parent directory.
  The PKG_CONFIG_PATH environment variable is not set.

  HINT: if you have installed the library, try setting PKG_CONFIG_PATH to the directory containing `glib-2.0.pc`.

Error: Process completed with exit code 101.

What can I do now to resolve this dependency as application building successfully on local Ubuntu 24.10 and Fedora 41?

Another my crates (1, 2) building well there and connected as crates to subject repository without any dependency issues.

2

In general, when you have a dependency on a C (or other foreign) library, there are two cases:

  • The Rust *-sys package may be able to compile a vendored copy. This is not an option for glib-sys.

  • You will have to install the relevant system package explicitly. In a GitHub workflow file this looks like adding a step:

    steps:
- uses: actions/checkout@v4
- name: Install system packages
  run: sudo apt-get install libglib2.0-dev
- name: Build
  run: cargo build --verbose
- name: Run tests
  run: cargo test --verbose
4 Likes
3

Thank you, now I understand where is the problem point!

but appending libglib2.0-dev does not help, suppose it related with Ubuntu 24.04 LTS version, not sure it contain gnome_47 features yet

4

I don't routinely use Ubuntu myself, so I might not have given the right package name.

1 Like
5

No, the package name you provided is valid, thanks - let me some time, trying to collect all dependencies for new installation on virtual machine, because on Fedora it looks like:

sudo dnf install git gcc\
                 cairo-devel glib2-devel gtk4-devel libadwaita-devel pango-devel\
                 sqlite-devel
6

I think it's related to Ubuntu version installed on GitHub, and there is not even 24.04 but 22.04 where glib version is 2.35 (I don't know how to check without CLI) - I think build error message just about the version, when trying to change it on local virtual machine, it works, but later got another versions problems, related to previous LTS.

So when GitHub plan upgrade their runner image to 24.04, my app already requires libadwaita 1.6+ (that's because maybe I've recently upgraded local Ubuntu machine to 24.10)

Anyway, found this useful example, includes PKG_CONFIG_PATH

but personally, give up with this integration as wonder GitHub uses old version of Ubuntu, not Fedora in development context. Maybe some relationship with MS.

7

You can switch to run in an arbitrary docker container, which you can test with locally:

So, for example:

# ...
jobs:
  fmt:
    name: Rustfmt
    runs-on: ubuntu-latest
    container: ubuntu:24.10 # short form
    steps:
      # ...

Though if you're doing this, you don't get any of the pre-installed stuff, so you might want to find a more specialized image to save time setting it up, or even to cook your own.

Just noticed you were referring to ubuntu-latest - you can also switch that to ubuntu-24.04 explicitly to opt into the newer version early.

Nah, AWS is often much slower for their managed services defaults. Just a quirk of these PaaS systems, you get relatively conservate defaults.

1 Like
8

wow, cool!

now I have expected warning

error: failed to run custom build command for `libadwaita-sys v0.7.1`

and seems ubuntu-24.10 is not an option
but anyway thank you for this tip!

UPD. thanks guys, finally have downgraded some non-critical libadwaita features to v 1.5
now application compatible with latest LTS and running build successfully!

9

Just one question, if I have added cargo clippy into the task, has it a sense to run cargo build after that?

I think that compilation is expensive action to overload their servers as actively commiting. Also interesting what about limits there, strange this feature is free.

10

Some errors may only appear when doing an actual build and not cargo check or cargo clippy; for example, errors relating to linking against foreign libraries, or certain constant evaluations.

However, in most cases, cargo test is more useful than cargo build and will have almost the same effect of building everything. So, I would suggest running cargo test in CI (along with cargo clippy), unless you are for some reason always going to have zero tests.

You can also use cargo test --no-run to build all tests but not run them, which is useful if you want to easily see the time taken for each; just run cargo test --no-run and cargo test as separate steps.

The free tier of GitHub Actions limits the number of jobs you can have running at once, and the virtual machines you get to use are fairly low-end (quite likely worse at building than the computer you’re writing on).

They also have terms of service specifying some things you are not allowed to use it for.

1 Like
11

Thanks for detailed explanation!

Found one issue - workflow does not warn about cargo clippy check fails.
At least it fails on local machine with same command:

warning: this expression creates a reference which is immediately dereferenced by the compiler
  --> src/app/browser/window/tab/item/page/content/text/gemini/reader/ansi.rs:17:35
   |
17 |     for entity in categorise_text(&source_code) {
   |                                   ^^^^^^^^^^^^ help: change this to: `source_code`
   |
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_borrow
   = note: `#[warn(clippy::needless_borrow)]` on by default

Current rust.yml:

name: Rust

on:
  push:
    branches: [ "master" ]
  pull_request:
    branches: [ "master" ]

env:
  CARGO_TERM_COLOR: always

jobs:
  build:

    runs-on: ubuntu-24.04

    steps:
    - uses: actions/checkout@v4
    - name: Run rustfmt
      run: cargo fmt --all -- --check
    - name: Install system packages
      run: sudo apt install -y libgtk-4-dev libadwaita-1-dev libsqlite3-dev
    - name: Run clippy
      run: cargo clippy --all-targets
    - name: Build
      run: cargo build --verbose
    - name: Run tests
      run: cargo test --verbose

Any ideas why?

12

If cargo clippy produces only warnings (not errors), then its exit code is still successful, so GitHub Actions will not count warnings as a failed task. The warnings should still be present in the logs.

If you want to have warnings count as a job failure you can configure that for the job like this:

env:
  RUSTFLAGS: '-Dwarnings'

Note that setting RUSTFLAGS will cause re-building.

1 Like
13

Oops, surprised that's really warning :slight_smile:

Rust community is awesome, like it ecosystem <3
thank you much

14

There's a way for jobs to show notices and warnings with links directly to the offending line:

I found someone had created a set of GitHub actions in the actions-rs · GitHub org that wrap calling the various commands and show these messages, but they're all archived with no explanation and will probably no longer run since they're using node 12?

However, if you dig into what they're doing, it looks like they're just emitting the half-undocumented "::add-matcher" command (it's documented for the toolkit, but not for scripts), so maybe that's yoinkable...

1 Like