Действия GitHub не создают двоичные файлы Rust

Я использую GitHub Actions для кросс-компиляции своей программы на Rust. Действие завершается успешно, в целевом каталоге создаются файлы, но двоичный файл отсутствует. Это мой рабочий файл:

name: Compile and save program

on:
  push:
    branches: [main]
    paths-ignore: ["samples/**", "**.md"]
  workflow_dispatch:
    
jobs:    
  build:
    strategy:
      fail-fast: false
      matrix:
        target: 
          - aarch64-unknown-linux-gnu
          - i686-pc-windows-gnu
          - i686-unknown-linux-gnu
          - x86_64-pc-windows-gnu
          - x86_64-unknown-linux-gnu
          
    name: Build executable
    runs-on: ubuntu-latest
    
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3
      - name: Set up Rust
        uses: actions-rs/toolchain@v1
        with:
          toolchain: stable
      - name: Install dependencies
        run: |
          rustup target add ${{ matrix.target }}
      - name: Build
        uses: actions-rs/cargo@v1
        with:
          use-cross: true
          command: build
          args: --target ${{ matrix.target }} --release --all-features --target-dir=/tmp
      - name: Debug missing files
        run: |
          echo "target dir:"
          ls -a /tmp/release
          echo "deps:"
          ls -a /tmp/release/deps
      - name: Archive production artifacts
        uses: actions/upload-artifact@v3
        with:
          name: ${{ matrix.target }}
          path: |
            /tmp/release

А это макет созданного каталога при нацеливании на Windows x86_64 (единственное отличие при нацеливании на другие платформы — это имена каталогов внутри .fingerprint и build):

.
├── .cargo-lock
├── .fingerprint/
│   ├── libc-d2565b572b77baea/
│   ├── winapi-619d3257e8f28792/
│   └── winapi-x86_64-pc-windows-gnu-7e7040207fbb5417/
├── build/
│   ├── libc-d2565b572b77baea/
│   ├── winapi-619d3257e8f28792/
│   └── winapi-x86_64-pc-windows-gnu-7e7040207fbb5417/
├── deps/
│   └── <empty>
├── examples/
│   └── <empty>
└── incremental/
    └── <empty>

Как видите, бинарника нет, и это отражено в загруженном артефакте.

Чем это вызвано?

РЕДАКТИРОВАТЬ 1

Программа отлично работает на моем локальном устройстве. Мой .cargo/config.toml ниже.

[target.aarch64-unknown-linux-gnu]
linker = "aarch64-linux-gnu-gcc"

А это мой Cargo.toml:

[package]
name = "brainfuck"
version = "0.4.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
console = "0.15.2"
either = "1.8.0"

РЕДАКТИРОВАТЬ 2

Возясь с тестовым репозиторием, я обнаружил, что эта проблема возникает только при указании цели. Если я не укажу цель и просто использую системную цель по умолчанию, я получу двоичный файл, как и ожидалось.

В вашей команде сборки вы переопределили целевой каталог как tmp: с флагом --target-dir=/tmp

Anonyme2000 05.11.2022 19:43

@ Anonyme2000 Я знаю, это то, куда смотрит команда ls, и оттуда загружается артефакт.

Spartan2909 05.11.2022 20:52

Вы уверены, что cargo удалось? Выводил что-нибудь? Как выглядит ваш проект? Вам нужно указать цель --bin?

Colonel Thirty Two 07.11.2022 00:26

@ColonelThirtyTwo Последний вывод из cargoFinished release [optimized] target(s) in 1m 47s. Мой проект состоит из двух файлов ржавчины. main.rs содержит основную логику программы, а text.rs — это библиотека, содержащая статические переменные, которыми я не хотел загромождать свой main.rs. Я добавлю больше деталей в пост.

Spartan2909 07.11.2022 10:16
Почему Python в конце концов умрет
Почему Python в конце концов умрет
Последние 20 лет были действительно хорошими для Python. Он прошел путь от "просто языка сценариев" до основного языка, используемого для написания...
0
4
79
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Оказывается, я не читал грузовые документы должным образом. В документах кеш сборки упоминается, что результаты сборки с указанной целью хранятся в target/<triple>/debug/, и именно там они и были.

Другие вопросы по теме