Giter Club home page Giter Club logo

upload-rust-binary-action's Introduction

upload-rust-binary-action

release build status

GitHub Action for building and uploading Rust binary to GitHub Releases.

Usage

This action builds and uploads Rust binary that specified by bin option to GitHub Releases.

Currently, this action is basically intended to be used in combination with an action like create-gh-release-action that creates a GitHub release when a tag is pushed. See also supported events.

Inputs

Name Required Description Type Default
bin true Comma-separated list of binary names (non-extension portion of filename) to build and upload String
token true [1] GitHub token for creating GitHub Releases (see action.yml for more) String
archive false Archive name (non-extension portion of filename) to be uploaded String $bin-$target
target false Target triple, default is host triple String (host triple)
features false Comma-separated list of cargo build features to enable String
no-default-features false Whether to disable cargo build default features Boolean false
tar false On which platform to distribute the .tar.gz file (all, unix, windows, or none) String unix
zip false On which platform to distribute the .zip file (all, unix, windows, or none) String windows
checksum false Comma-separated list of algorithms to be used for checksum (sha256, sha512, sha1, or md5) String
include false Comma-separated list of additional files to be included to the archive String
asset false Comma-separated list of additional files to be uploaded separately String
leading-dir false Whether to create the leading directory in the archive or not Boolean false
build-tool false Tool to build binaries (cargo, cross, or cargo-zigbuild, see cross-compilation example for more) String
ref false Fully-formed tag ref for this release (see action.yml for more) String
manifest-path false Path to Cargo.toml String Cargo.toml
profile false The cargo profile to build. This defaults to the release profile. String release
dry-run false Build and compress binaries, but do not upload them (see action.yml for more) Boolean false
codesign false Sign build products using codesign on macOS String

[1] Required one of token input option or GITHUB_TOKEN environment variable. Not required when dry-run input option is set to true.

(Previously, option names were only in "snake_case", but now both "kebab-case" and "snake_case" are available.)

Example workflow: Basic usage

In this example, when a new tag is pushed, creating a new GitHub Release by using create-gh-release-action, then uploading Rust binary to the created GitHub Release.

An archive file with a name like $bin-$target.tar.gz will be uploaded to GitHub Release.

name: Release

permissions:
  contents: write

on:
  push:
    tags:
      - v[0-9]+.*

jobs:
  create-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: taiki-e/create-gh-release-action@v1
        with:
          # (optional) Path to changelog.
          changelog: CHANGELOG.md
          # (required) GitHub token for creating GitHub Releases.
          token: ${{ secrets.GITHUB_TOKEN }}

  upload-assets:
    needs: create-release
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: taiki-e/upload-rust-binary-action@v1
        with:
          # (required) Comma-separated list of binary names (non-extension portion of filename) to build and upload.
          # Note that glob pattern is not supported yet.
          bin: ...
          # (required) GitHub token for uploading assets to GitHub Releases.
          token: ${{ secrets.GITHUB_TOKEN }}

You can specify multiple binaries when the root manifest is a virtual manifest or specified binaries are in the same crate.

- uses: taiki-e/upload-rust-binary-action@v1
  with:
    # (required) Comma-separated list of binary names (non-extension portion of filename) to build and upload.
    # Note that glob pattern is not supported yet.
    bin: app1,app2
    # (optional) Archive name (non-extension portion of filename) to be uploaded.
    # [default value: $bin-$target]
    # [possible values: the following variables and any string]
    #   variables:
    #     - $bin    - Binary name (non-extension portion of filename).
    #     - $target - Target triple.
    #     - $tag    - Tag of this release.
    # When multiple binary names are specified, default archive name or $bin variable cannot be used.
    archive: app-$target
    # (required) GitHub token for uploading assets to GitHub Releases.
    token: ${{ secrets.GITHUB_TOKEN }}

Example workflow: Basic usage (multiple platforms)

This action supports Linux, macOS, and Windows as a host OS and supports binaries for various targets.

See also cross-compilation example.

name: Release

permissions:
  contents: write

on:
  push:
    tags:
      - v[0-9]+.*

jobs:
  create-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: taiki-e/create-gh-release-action@v1
        with:
          # (optional) Path to changelog.
          changelog: CHANGELOG.md
          # (required) GitHub token for creating GitHub Releases.
          token: ${{ secrets.GITHUB_TOKEN }}

  upload-assets:
    needs: create-release
    strategy:
      matrix:
        os:
          - ubuntu-latest
          - macos-latest
          - windows-latest
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v4
      - uses: taiki-e/upload-rust-binary-action@v1
        with:
          # (required) Comma-separated list of binary names (non-extension portion of filename) to build and upload.
          # Note that glob pattern is not supported yet.
          bin: ...
          # (optional) On which platform to distribute the `.tar.gz` file.
          # [default value: unix]
          # [possible values: all, unix, windows, none]
          tar: unix
          # (optional) On which platform to distribute the `.zip` file.
          # [default value: windows]
          # [possible values: all, unix, windows, none]
          zip: windows
          # (required) GitHub token for uploading assets to GitHub Releases.
          token: ${{ secrets.GITHUB_TOKEN }}

Example workflow: Customize archive name

By default, this action will upload an archive file with a name like $bin-$target.$extension.

You can customize archive name by archive option.

name: Release

permissions:
  contents: write

on:
  push:
    tags:
      - v[0-9]+.*

jobs:
  create-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: taiki-e/create-gh-release-action@v1
        with:
          # (optional) Path to changelog.
          changelog: CHANGELOG.md
          # (required) GitHub token for creating GitHub Releases.
          token: ${{ secrets.GITHUB_TOKEN }}

  upload-assets:
    needs: create-release
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: taiki-e/upload-rust-binary-action@v1
        with:
          bin: ...
          # (optional) Archive name (non-extension portion of filename) to be uploaded.
          # [default value: $bin-$target]
          # [possible values: the following variables and any string]
          #   variables:
          #     - $bin    - Binary name (non-extension portion of filename).
          #     - $target - Target triple.
          #     - $tag    - Tag of this release.
          # When multiple binary names are specified, default archive name or $bin variable cannot be used.
          archive: $bin-$tag-$target
          # (required) GitHub token for uploading assets to GitHub Releases.
          token: ${{ secrets.GITHUB_TOKEN }}

Example workflow: Build with different features on different platforms

This action enables the systemd and io_uring features for Linux, and leave macOS, and Windows with default set of features.

name: Release

permissions:
  contents: write

on:
  push:
    tags:
      - v[0-9]+.*

jobs:
  create-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: taiki-e/create-gh-release-action@v1
        with:
          # (optional) Path to changelog.
          changelog: CHANGELOG.md
          # (required) GitHub token for creating GitHub Releases.
          token: ${{ secrets.GITHUB_TOKEN }}

  upload-assets:
    needs: create-release
    strategy:
      matrix:
        os: [ubuntu-latest, macos-latest, windows-latest]
        include:
          - os: ubuntu-latest
            features: systemd,io_uring
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v4
      - uses: taiki-e/upload-rust-binary-action@v1
        with:
          # (required) Comma-separated list of binary names (non-extension portion of filename) to build and upload.
          # Note that glob pattern is not supported yet.
          bin: ...
          # (optional) On which platform to distribute the `.tar.gz` file.
          # [default value: unix]
          # [possible values: all, unix, windows, none]
          tar: unix
          # (optional) On which platform to distribute the `.zip` file.
          # [default value: windows]
          # [possible values: all, unix, windows, none]
          zip: windows
          # (optional) Build with the given set of features if any.
          features: ${{ matrix.features || '' }}
          # (required) GitHub token for uploading assets to GitHub Releases.
          token: ${{ secrets.GITHUB_TOKEN }}

Example workflow: Cross-compilation

cross

By default, this action uses cross for cross-compilation (if cross supports that target). In the following example, only aarch64-unknown-linux-gnu uses cross, the rest use cargo.

If cross is not installed, this action calls cargo install cross --locked to install cross. If you want to speed up the installation of cross or use an older version of cross, consider using install-action.

name: Release

permissions:
  contents: write

on:
  push:
    tags:
      - v[0-9]+.*

jobs:
  create-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: taiki-e/create-gh-release-action@v1
        with:
          # (optional) Path to changelog.
          changelog: CHANGELOG.md
          # (required) GitHub token for creating GitHub Releases.
          token: ${{ secrets.GITHUB_TOKEN }}

  upload-assets:
    needs: create-release
    strategy:
      matrix:
        include:
          - target: aarch64-unknown-linux-gnu
            os: ubuntu-latest
          - target: aarch64-apple-darwin
            os: macos-latest
          - target: x86_64-unknown-linux-gnu
            os: ubuntu-latest
          - target: x86_64-apple-darwin
            os: macos-latest
          # Universal macOS binary is supported as universal-apple-darwin.
          - target: universal-apple-darwin
            os: macos-latest
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v4
      - uses: taiki-e/upload-rust-binary-action@v1
        with:
          # (required) Comma-separated list of binary names (non-extension portion of filename) to build and upload.
          # Note that glob pattern is not supported yet.
          bin: ...
          # (optional) Target triple, default is host triple.
          target: ${{ matrix.target }}
          # (required) GitHub token for uploading assets to GitHub Releases.
          token: ${{ secrets.GITHUB_TOKEN }}

setup-cross-toolchain-action

However, if the host has another cross-compilation setup, it will be respected. The following is an example using setup-cross-toolchain-action. In this example, this action uses cargo for all targets.

name: Release

permissions:
  contents: write

on:
  push:
    tags:
      - v[0-9]+.*

jobs:
  create-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: taiki-e/create-gh-release-action@v1
        with:
          # (optional) Path to changelog.
          changelog: CHANGELOG.md
          # (required) GitHub token for creating GitHub Releases.
          token: ${{ secrets.GITHUB_TOKEN }}

  upload-assets:
    needs: create-release
    strategy:
      matrix:
        include:
          - target: aarch64-unknown-linux-gnu
            os: ubuntu-latest
          - target: aarch64-apple-darwin
            os: macos-latest
          - target: x86_64-unknown-linux-gnu
            os: ubuntu-latest
          - target: x86_64-apple-darwin
            os: macos-latest
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v4
      - name: Install cross-compilation tools
        uses: taiki-e/setup-cross-toolchain-action@v1
        with:
          target: ${{ matrix.target }}
        if: startsWith(matrix.os, 'ubuntu')
      - uses: taiki-e/upload-rust-binary-action@v1
        with:
          # (required) Comma-separated list of binary names (non-extension portion of filename) to build and upload.
          # Note that glob pattern is not supported yet.
          bin: ...
          # (optional) Target triple, default is host triple.
          target: ${{ matrix.target }}
          # (required) GitHub token for uploading assets to GitHub Releases.
          token: ${{ secrets.GITHUB_TOKEN }}

cargo-zigbuild

if you want to use cargo-zigbuild, if the heuristic to detect host cross-compilation setups does not work well, or if you want to force the use of cargo or cross, you can use the build-tool input option.

If cargo-zigbuild is not installed, this action calls pip3 install cargo-zigbuild to install cargo-zigbuild.

name: Release

on:
  push:
    tags:
      - v[0-9]+.*

jobs:
  create-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: taiki-e/create-gh-release-action@v1
        with:
          # (optional)
          changelog: CHANGELOG.md
          # (required)
          token: ${{ secrets.GITHUB_TOKEN }}

  upload-assets:
    needs: create-release
    strategy:
      matrix:
        include:
          - target: x86_64-unknown-linux-gnu
            os: ubuntu-latest
            build-tool: cargo-zigbuild
          # cargo-zigbuild's glibc version suffix is also supported.
          - target: aarch64-unknown-linux-gnu.2.17
            os: ubuntu-latest
            build-tool: cargo-zigbuild
          - target: aarch64-apple-darwin
            os: macos-latest
            build-tool: cargo
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v4
      - uses: taiki-e/upload-rust-binary-action@v1
        with:
          # (required)
          bin: ...
          # (optional) Target triple, default is host triple.
          target: ${{ matrix.target }}
          # (optional) Tool to build binaries (cargo, cross, or cargo-zigbuild)
          build-tool: ${{ matrix.build-tool }}
          # (required) GitHub token for uploading assets to GitHub Releases.
          token: ${{ secrets.GITHUB_TOKEN }}

Example workflow: Include additional files

If you want include additional file to the archive, you can use the include option.

name: Release

permissions:
  contents: write

on:
  push:
    tags:
      - v[0-9]+.*

jobs:
  create-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: taiki-e/create-gh-release-action@v1
        with:
          # (optional) Path to changelog.
          changelog: CHANGELOG.md
          # (required) GitHub token for creating GitHub Releases.
          token: ${{ secrets.GITHUB_TOKEN }}

  upload-assets:
    needs: create-release
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: taiki-e/upload-rust-binary-action@v1
        with:
          # (required) Comma-separated list of binary names (non-extension portion of filename) to build and upload.
          # Note that glob pattern is not supported yet.
          bin: ...
          # (optional) Comma-separated list of additional files to be included to archive.
          # Note that glob pattern is not supported yet.
          include: LICENSE,README.md
          # (required) GitHub token for uploading assets to GitHub Releases.
          token: ${{ secrets.GITHUB_TOKEN }}

By default, the expanded archive does not include the leading directory. In the above example, the directory structure of the archive would be as follows:

/<bin>
/LICENSE
/README.md

You can use the leading-dir option to create the leading directory.

- uses: taiki-e/upload-rust-binary-action@v1
  with:
    # (required) Comma-separated list of binary names (non-extension portion of filename) to build and upload.
    # Note that glob pattern is not supported yet.
    bin: ...
    # (optional) Comma-separated list of additional files to be included to archive.
    # Note that glob pattern is not supported yet.
    include: LICENSE,README.md
    # (optional) Whether to create the leading directory in the archive or not. default to false.
    leading-dir: true
    # (required) GitHub token for uploading assets to GitHub Releases.
    token: ${{ secrets.GITHUB_TOKEN }}

In the above example, the directory structure of the archive would be as follows:

/<archive>/
/<archive>/<bin>
/<archive>/LICENSE
/<archive>/README.md

If you want upload additional file separately, you can use the asset option.

upload-assets:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - uses: taiki-e/upload-rust-binary-action@v1
      with:
        # (required) Comma-separated list of binary names (non-extension portion of filename) to build and upload.
        # Note that glob pattern is not supported yet.
        bin: ...
        # (optional) Comma-separated list of additional files to be uploaded separately.
        # Note that glob pattern is not supported yet.
        asset: LICENSE,README.md
        # (required) GitHub token for uploading assets to GitHub Releases.
        token: ${{ secrets.GITHUB_TOKEN }}

In the above example, the following 3 files will be uploaded:

<bin>-<target>.tar.gz
LICENSE
README.md

Other examples

Optimize Rust binary

You can optimize performance or size of Rust binaries by passing the profile options. The profile options can be specified by [profile] table in Cargo.toml, cargo config, environment variables, etc.

The followings are examples to specify profile options:

  • lto

    With profile:

    [profile.release]
    lto = true

    With environment variable:

    env:
      CARGO_PROFILE_RELEASE_LTO: true
  • codegen-units

    With profile:

    [profile.release]
    codegen-units = 1

    With environment variable:

    env:
      CARGO_PROFILE_RELEASE_CODEGEN_UNITS: 1
  • strip

    With profile:

    [profile.release]
    strip = true

Note: Some of these options may increase the build time.

Supported events

The following two events are supported by default:

  • tags (on.push.tags)

    For example:

    on:
      push:
        tags:
          - v[0-9]+.*
  • GitHub release (on.release)

    For example:

    on:
      release:
        types: [created]

You can upload binaries from arbitrary event to arbitrary tag by specifying the ref input option.

For example, to upload binaries to the my_tag tag, specify ref input option as follows:

with:
  ref: refs/tags/my_tag

Compatibility

This action has been tested for GitHub-hosted runners (Ubuntu, macOS, Windows). To use this action in self-hosted runners or in containers, at least the following tools are required:

  • rustup, cargo, rustc
  • bash, GNU Coreutils, GNU grep, GNU tar
  • gh (GitHub CLI)
  • zip (only Unix-like)
  • 7z (only Windows)

Related Projects

License

Licensed under either of Apache License, Version 2.0 or MIT license at your option.

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

upload-rust-binary-action's People

Contributors

afnanenayet avatar doinkythederp avatar georgehahn avatar ririsoft avatar samtay avatar sunshowers avatar taiki-e avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

upload-rust-binary-action's Issues

Warning: arm-linux-gnueabihf-strip not found, skip stripping

When running release jobs using this action and cross compiling to Linuxes that are not x86-64 or i686 I get the following warnings in the builds:

upload-assets (aarch64-unknown-linux-musl, ubuntu-latest)
aarch64-linux-gnu-strip not found, skip stripping

upload-assets (armv7-unknown-linux-musleabihf, ubuntu-latest)
arm-linux-gnueabihf-strip not found, skip stripping

upload-assets (aarch64-unknown-linux-gnu, ubuntu-latest)
aarch64-linux-gnu-strip not found, skip stripping

upload-assets (armv7-unknown-linux-gnueabihf, ubuntu-latest)
arm-linux-gnueabihf-strip not found, skip stripping

Here is an example run of this: https://github.com/VorpalBlade/chezmoi_modify_manager/actions/runs/6699435637
And the relevant workflow: https://github.com/VorpalBlade/chezmoi_modify_manager/blob/main/.github/workflows/release.yml (specifically the job upload-assets).

Am I doing something wrong? Or is it a bug in the action whereby it doesn't install some required dependency? I seem to be doing the same things you do in your examples in your README though.

Cannot strip ARM binaries

I am using this action to cross-compile a CLI application (called hoard) for multiple platforms. When compiling for the armv7-linux-androideabi target, I got the following error:

strip: Unable to recognise the format of the input file `hoard'

I am not sure if there is a way to strip these binaries or if stripping should be skipped for them, but either solution would be nice so I can distribute downloads for Android platforms.

Support signing releases

Things that appear to be the standard for each platform:

Other interesting things:

Refs:

Support for use on non-tags

Something I've noticed is that the current action can only be executed from a tag, due to these lines:

if [[ "${ref}" != "refs/tags/"* ]]; then
bail "tag ref should start with 'refs/tags/': '${ref}'"
fi
tag="${ref#refs/tags/}"

There are cases that a binary release might be run from a branch rather than from a tag. An example of this is when retroactively running a CI job for an already released tag.

Build dynamic libraries with binaries

By default cargo build will build all workspace members including binaries and libraries, but this action requires adding the --bin flag which only builds binaries, can the bin option be made optional and default to normal cargo build without it?

EDIT: The include option is also a bit useless if it fails the action if it cant find a file, there may be platform dependent files such as libexample.so and example.dll but all builds fail when one of them doesn't match on one target matrix.

Support (or document) fully-static builds with 'musl'

First of all, thanks a lot for working on this GitHub Action! ๐Ÿ™๐Ÿป
It's amazing how smoothly it works ๐Ÿคฏ I was able to configure binary releases with GitHub Actions in a matter of minutes and everything worked even better than I expected.

When creating a release of my tool, I've noticed that the asset has name tool-x86_64-unknown-linux-gnu.tar.gz and that the binary is actually dynamically linked:

$ ldd tool 
	linux-vdso.so.1 (0x00007fff1e19e000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f89aa7ac000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f89aa7a7000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f89aa6c0000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f89aa6bb000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f89aa493000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f89aaaee000)

Is there a way to create statically linked binaries with musl?

Here is my release workflow:


I've noticed an example usage of musl in the following repository:

          - target: x86_64-unknown-linux-gnu
          - target: x86_64-unknown-linux-musl

But I'm not quite sure how it works ๐Ÿค” Could you explain how can I use this workflow to link my binary statically?

Thanks a lot! ๐Ÿ™๐Ÿป

Including version number in the file names?

Currently the name format seems to be <binary-name>-<target-triplet>.<zip/tar.gz>. For compatibility with self_update it would be great if it was possible to configure the name to <binary name>-<version>-<target-triplet>.<zip/tar.gz>.

See also jaemk/self_update#107. It might be possible to manually make self_update work with the conventions here, but it would be a lot easier if this supported including the version number.

Split debuginfos in addition to stripping

Since this action does all: compiling, stripping, and uploading, it's currently not possible to retain debuginfos in a separate file, since they're just stripped away immediately after building. Debuginfos are important for debuggers and profilers to work though so it would be nice if there was some way to enable keeping them.

Would you be open to in addition to stripping adding an object copy that first extracts debuginfos? For example here:

objcopy --only-keep-debug "${target_dir}/${bin_exe}" "${target_dir}/${bin_exe}.debug"

how to compile under centos

user follow yml

  upload-assets:
    runs-on: ubuntu-latest
    container: centos:7
    steps:
      - uses: actions/checkout@v3
      
      - name: Initialization environment
        run: |
          yum install -y libpcap-devel

      - uses: taiki-e/upload-rust-binary-action@v1
        with:
          # (required) Comma-separated list of binary names (non-extension portion of filename) to build and upload.
          # Note that glob pattern is not supported yet.
          bin: mytest
          # (required) GitHub token for uploading assets to GitHub Releases.
          token: ${{ secrets.GITHUB_TOKEN }}

github action got error

Run bash --noprofile --norc "${GITHUB_ACTION_PATH:?}/main.sh"
/__w/_actions/taiki-e/upload-rust-binary-action/v1/main.sh: line 120: rustc: command not found

cross-compilation errors

I am trying to cross-compile a program. There is the matrix of all the values that I defined:

      matrix:
        include:
          # Ubuntu
          - target: aarch64-unknown-linux-gnu
            os: ubuntu-latest
          - target: x86_64-unknown-linux-gnu
            os: ubuntu-latest
          # Mac OS
          - target: aarch64-apple-darwin
            os: macos-latest
          - target: x86_64-apple-darwin
            os: macos-latest
          - target: universal-apple-darwin
            os: macos-latest
          # Windows
          - target: x86_64-pc-windows-msvc
            os: windows-latest

When compiling for Linux, I get the following output below. I tried installing libssl-dev in the GitHub action but it does not solve the problem.

Any idea how to solve this?

Thanks!

error: failed to run custom build command for `openssl-sys v0.9.90`

Caused by:
  process didn't exit successfully: `/home/runner/work/stella/stella/target/release/build/openssl-sys-aae445923f341257/build-script-main` (exit status: 101)
  --- stdout
  cargo:rerun-if-env-changed=AARCH64_UNKNOWN_LINUX_GNU_OPENSSL_LIB_DIR
  AARCH64_UNKNOWN_LINUX_GNU_OPENSSL_LIB_DIR unset
  cargo:rerun-if-env-changed=OPENSSL_LIB_DIR
  OPENSSL_LIB_DIR unset
  cargo:rerun-if-env-changed=AARCH64_UNKNOWN_LINUX_GNU_OPENSSL_INCLUDE_DIR
  AARCH64_UNKNOWN_LINUX_GNU_OPENSSL_INCLUDE_DIR unset
  cargo:rerun-if-env-changed=OPENSSL_INCLUDE_DIR
  OPENSSL_INCLUDE_DIR unset
  cargo:rerun-if-env-changed=AARCH64_UNKNOWN_LINUX_GNU_OPENSSL_DIR
  AARCH64_UNKNOWN_LINUX_GNU_OPENSSL_DIR unset
  cargo:rerun-if-env-changed=OPENSSL_DIR
  OPENSSL_DIR unset
  cargo:rerun-if-env-changed=OPENSSL_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS_aarch64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS_aarch64_unknown_linux_gnu
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_ALLOW_CROSS
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS
  cargo:rerun-if-env-changed=PKG_CONFIG_aarch64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_aarch64_unknown_linux_gnu
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_aarch64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_aarch64_unknown_linux_gnu
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
  run pkg_config fail: pkg-config has not been configured to support cross-compilation.

  Install a sysroot for the target platform and configure it via
  PKG_CONFIG_SYSROOT_DIR and PKG_CONFIG_PATH, or install a
  cross-compiling wrapper for pkg-config and set it via
  PKG_CONFIG environment variable.

  --- stderr
  thread 'main' panicked at '

  Could not find directory of OpenSSL installation, and this `-sys` crate cannot
  proceed without this knowledge. If OpenSSL is installed and this crate had
  trouble finding it,  you can set the `OPENSSL_DIR` environment variable for the
  compilation process.

  Make sure you also have the development packages of openssl installed.
  For example, `libssl-dev` on Ubuntu or `openssl-devel` on Fedora.

  If you're in a situation where you think the directory *should* be found
  automatically, please open a bug at https://github.com/sfackler/rust-openssl
  and include information about your system as well as this message.

  $HOST = x86_64-unknown-linux-gnu
  $TARGET = aarch64-unknown-linux-gnu
  openssl-sys = 0.9.90

  ', /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/openssl-sys-0.9.90/build/find_normal.rs:190:5
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
Error: Process completed with exit code 101.

Build with nightly

Is it possible to release using nightly toolchain rather than stable?

Codesign on macOS

It would be nice to have the opportunity to run codesign on the built binary before uploading it! This would help to appease macOS's Gatekeeper.

Reimplement the core part with Rust

As more features are added, it becomes more difficult to maintain a shell script based implementation.

The preferred solution here is to create a command line interface to handle these in Rust, as we have already done with the changelog handling of create-gh-release-action, and then download and use that binary in the action.

https://github.com/taiki-e/create-gh-release-action/blob/b0409209a3d4447b543ddbc3305d9e0c191eeaa8/main.sh#L66-L69

Related: taiki-e/create-gh-release-action#9

build error: requires at least 2 arg(s), only received 1

Hi~ when i push my code to trigger the gitflow, i receive the error :

requires at least 2 arg(s), only received
Error: Command failed: bash --noprofile --norc /home/runner/work/_actions/taiki-e/upload-rust-binary-action/v1/main.sh

Did i do something wrong? Please help me, Ths!

relevant yml:

      - name: "Upload Binaries"
        uses: "taiki-e/upload-rust-binary-action@v1"
        with:
          bin: ${{ needs.get-tag.outputs.bin-name }} 
          target: ${{ matrix.target }}
          archive: $bin-${{ matrix.target }}
          tar: none
          ref: refs/tags/v${{ needs.get-tag.outputs.pkg-version }}
          token: ${{ secrets.GITHUB_TOKEN }}

Support upx

upx produces runnable compressed binaries. It will be greatly useful, if this action can support it.

Dependency install for specific matrix.os

Hi, I want to install some dependencies before compile, but I cannot make it work. Here is my yml file:

name: Release

permissions:
  contents: write

on:
  push:
    tags:
      - v[0-9]+.*

env:
  CARGO_TERM_COLOR: always

jobs:
  create-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: taiki-e/create-gh-release-action@v1
        with:
          # (required) GitHub token for creating GitHub Releases.
          token: ${{ secrets.GITHUB_TOKEN }}


  upload-assets:
    strategy:
      matrix:
        include:
          - target: x86_64-unknown-linux-gnu
            os: ubuntu-latest
          - target: aarch64-apple-darwin
            os: macos-latest
          - target: x86_64-apple-darwin
            os: macos-latest
          - target: x86_64-pc-windows-msvc
            os: windows-latest
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v3
        if: startsWith(matrix.os, 'ubuntu')
      - name: Set the version
        shell: bash
        run: sudo apt-get install -y pkg-config libx11-dev libxi-dev libgl1-mesa-dev libasound2-dev
      - uses: taiki-e/upload-rust-binary-action@v1
        with:
          # (required)
          bin: rustyed
          include: rustyed.conf,fonts
          asset: rustyed.conf
          target: ${{ matrix.target }}
          # (optional) On which platform to distribute the `.tar.gz` file.
          # [default value: unix]
          # [possible values: all, unix, windows, none]
          tar: unix
          # (optional) On which platform to distribute the `.zip` file.
          # [default value: windows]
          # [possible values: all, unix, windows, none]
          zip: windows
        env:
          # (required)
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

When action runs it runs shell command on all OSes and thus it's fail.

How can I install dependencies for specific os before compile & release action happen.

Retry 500 errors from `gh release`

See this example release run: ci link.
Upload failed with the following output.

+ gh release upload v0.3.0 cargo-marker-x86_64-unknown-linux-gnu.tar.gz cargo-marker-x86_64-unknown-linux-gnu.zip cargo-marker-x86_64-unknown-linux-gnu.sha256 --clobber
HTTP 502: Server Error (https://api.github.com/repos/Veetaha/marker/releases/assets/125294025)
Error: Process completed with exit code 1.

I suggest using exponential backoff to retry the gh release operation when it fails.
Here is an example bash function that we use to retry any network operations.

Uncompressed binary

I see that there is no way to avoid compression since setting tar and zip both to none will generate an error. Would be nice to have a way to skip compression and upload an uncompressed binary as it makes it easier to use in a shell script.

sha256sum not found on macOS runners

When using the checksum field of this action with the sha256 field, I see the following error on macOS runners:

/Users/runner/work/_actions/taiki-e/upload-rust-binary-action/v1/main.sh: line 277: sha256sum: command not found
Error: Command failed: bash --noprofile --norc /Users/runner/work/_actions/taiki-e/upload-rust-binary-action/v1/main.sh

The checksum tool is called here:

"${checksum}sum" "${assets[@]}" >"${archive}.${checksum}"

Apparenty, sha256sum is not installed on macOS by default:

Workaround for users

Install coreutils with brew to bring sha256sum into the scope:

- name: Install coreutils for macOS
  if: matrix.os == 'macOS-latest'
  run: brew install coreutils

Fix in the action

Use the shasum tool on macOS with the -a option

shasum -a 256 foo.txt > foo-sha256.txt

Add a dry-run mode

Hi, thank you for the great action ๐Ÿ‘‹

I would like to test if my app compiles in CI for a certain target before creating the tag or the release.

It would be nice if this action provided a dry-run flag in the inputs, so that in our PRs we can test that our yaml works :)
When dry-run == true, the upload-rust-binary-action just checks if the binary compiles, without publishing it (similarly to cargo publish --dry-run).

Action fails if Github CLI not installed

/opt/gha-runner/_work/_actions/taiki-e/upload-rust-binary-action/v1/main.sh: line 264: gh: command not found
Error: Command failed: bash --noprofile --norc /opt/gha-runner/_work/_actions/taiki-e/upload-rust-binary-action/v1/main.sh

Found this when running on my self-hosted runners on ubuntu-20.04.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.