actions-rs/meta

🦀 GitHub Actions for Rust - recipes, discussions, questions and ideas

meta's Issues

Add `rustfmt-check`

Would it be difficult to adapt clippy-check to create rustfmt-check?

There is the same --mesage-format=json option for cargo fmt, though currently it is in a bit of limbo on stable (rust-lang/rustfmt#3947).

I tried forking clippy-check to create rustfmt-check, but was unable to get npm to install the right dependencies and I'm not sure how things are meant to work. You can see the 'fork' at https://github.com/JP-Ellis/rustfmt-check and a test crate using it at https://github.com/JP-Ellis/test-rustfmt-check and if I'm on the right track, help would be appreciated.

Caching of Build Artifacts

I'm not sure if this is actually possible with GitHub Actions (yet?) but it would be cool to be able to cache the target directory between builds for some speedups.

Dependencies to private repos?

Can't fetch private Github repos when running actions (declared similarly to here note: this is not the the repo with the private deps):

failed to get `x` as a dependency of package `y v0.1.0 (/home/runner/work/y/y)`

I tried this out but it didn't work: https://gist.github.com/kestein/87d8bb9cef187c0d02d733138a0a4454

The private repos work on my local environment (via CARGO_NET_GIT_FETCH_WITH_CLI=true in the .env).

[discussion] denser syntax for installing rustc + components

Consider this job:

  check_fmt:
    name: Checking fmt
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@master

    - id: component
      uses: actions-rs/components-nightly@v1
      with:
        component: rustfmt

    - uses: actions-rs/toolchain@v1
      with:
          toolchain: ${{ steps.component.outputs.toolchain }}
          override: true

    - name: fmt
      run: cargo fmt --all -- --check

There's a subtle bug hiding here that takes a bit of reading to figure out. Namely, despite the fact that we're talking about rustfmt multiple times, we're never actually installing rustfmt. This requires an extra line of run: rustup component add rustfmt.

So I was thinking of ways in which this could be improved, and realized that currently we're still working with how we should do things, rather than declaring what we want. I would imagine a declarative syntax for the same of what we've done above to be:

  check_fmt:
    name: Checking fmt
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@master

    - uses: actions-rs/toolchain@v1
      with:
          toolchain: nightly
          components:
              - rustfmt

    - name: fmt
      run: cargo fmt --all -- --check

This would apply the automatic version fallback from components-nightly behind the scenes, but only for the components specified. And possibly even handle resolution for when there are multiple components that may need to be installed, ensuring that all of them exist on the version that's being installed (because selecting them individually could be unreliable when doing this manually; it's not common, but I've hit this at least once).

Hopefully this is a useful idea, and I mostly just wanted to open up a conversation on if we could perhaps simplify some of the workflows. Thanks heaps!

Donating action-rust-aws-lambda

Hi,

As one of my projects was finally migrated to Github Action, I needed a way to release AWS Lambda compatible binaries. Thus I decided to put some lines of code together and create a custom action the generates this build for me. It is a port of the steps described by the official AWS Lambda Runtime for Rust.

Just as the toolchain action is useful for me, I believe my ad-hoc action might be useful for other people too. Therefore I decided to donate it to the actions-rs, of course, if you think it makes sense.

Here is the original source code. Please let me know your thoughts and how can I help in the process.

https://github.com/miere/action-rust-aws-lambda

cargo miri

This is currently possible by installing the necessary components and first running cargo install xargo, but caching would be particularly useful here as xargo has to be built and then miri needs everything (even std) compiled clean to suit itself.

semverver

@yaahc proposed an idea to add Action with semverver tool.

So far there are two possible options to use it:

1. Same to other *-check Actions, execute it on: [push, pull_request] and add check annotations with the compliance notes.
2. Execute it on a release: published event (idea goes to @yahhc) and fail the check for it if there were any compliance issues.

Unresolved questions:

1. Should it fail the execution in case if any notes were found? Looks like there a multiple categories exist (Patch, NonBreaking, TechnicallyBreaking, and Breaking); how should the check act at all?
2. Relying on release: published event would mean that it is expected from users to tag-and-push first and do the cargo publish only after the action succeeds/fails? Is it okay?
3. With what version should it be compared to? We should probably make an API call to the crates.io and fetch latest version from there

Any ideas and suggestions will be much appreciated!

Source-based coverage

Motivation

I'd love to see support for the new source-based profiling as an action, similar to grcov and tarpaulin actions.

Additional context

See https://blog.rust-lang.org/inside-rust/2020/11/12/source-based-code-coverage.html

Show clippy warning names in GH UI

Motivation

I'm just integrating CI with actions-rs on my project and I got a couple of clippy warnings, these show up in the GH UI properly:

But it'd be nice to have the warning name (clippy::too-many-arguments) in the GH pop-up thingy to easily disable them if I needed too.

Workflow example

I pretty much copied the Matrix example: https://github.com/jjant/runty8/pull/27/files#diff-73e17259d77e5fbef83b2bdbbe4dc40a912f807472287f7f45b77e0cbf78792d

cargo udeps

Use https://github.com/est31/cargo-udeps to check if all dependencies are used

Native dependencies

I tried adding CI to my project, but build fails because native dependencies are not installed. And I'd like to know what the recommended way to deal with these is. I could do a - run: apt install $package, but maybe there is a better way? Especially, I want the CI to run in a Matrix on both Ubuntu and Windows, and I have no clue about the Windows part.

Add caching action/example?

GHA supports caching now! It would be awesome to have either an example or a wrapper action for dealing with dependency builds and maybe even tooling installs?

cargo tomlfmt

We use the cargo-tomlfmt binary to enforce a certain formatting of the Cargo.toml files.

Specifically, we sort the list of dependencies alphabetically which helps with avoiding merge conflicts.

Would you consider creating an action that allows to use this tool without having to install it every time?
Installing it takes somewhere around 4 minutes.

References:

• https://github.com/tbrand/cargo-tomlfmt

Support a release action

Hi ! Thanks for all the actions :)

Would be amazing to have a release action that would

1. build and test everything
2. bump the version
3. tag in git
4. publish to crates.io but also to github releases

https://github.com/sunng87/cargo-release does most of the above

What do you think ?

Cargo Fails to Download a Random Crate

Discussed in #41

^{Originally posted by gluax July 9, 2021}
Hey all.

Has anyone else been having an issue with cargo from action-rs? Our pipelines will fail at random depending on whether cargo successfully downloads all crate dependencies. The dependency it fails on is random each time, and our circle ci instances have no issues fetching all dependencies. This has been happening a lot recently, and it's blocking us.

Bringing to an issue, since I see other repo's facing the same issue.

Security considerations

Github actions are a target for any malicious actors as they have access to secrets like crates.io login tokens for potentially thousands of crates.

This organisation is likely to become the defacto standard for Rust Github actions. As such you should put in place (and document) some basic security precautions. For example:

• Require 2FA for all members.
• Limit within the org who can publish changes to widely used actions.

To name a couple of options.

How to release artifacts builds on several operating systems?

Hello there,

I'm trying to port CI of TankerHQ/dmenv from travis to GitHub actions, but I'm stuck at the publishing workflow :/

When a tag is pushed, I want to:

• create a GitHub release matching the tag
• build dmenv.exe on Windows, dmenv-osx and dmenv-linux on the 3 matching operating systems
• upload those binaries as assets

Here's what I've tried

jobs:
  release:
   runs-on: ${{ matrix.os }}
    strategy:
       matrix:
          os: [ubuntu-latest, macos-latest, windows-latest]
    steps:
     - name: "Create GitHub Release"
        id: "create_release"
        uses: actions/[email protected]
        # ...

   - name: Build
     # ...

   - name: Upload release assets for linux
      if: matrix.os == 'ubuntu-latest'
      uses: actions/[email protected]
      with:
        upload_url: ${{ steps.create_release.outputs.upload_url }}
        asset_path: target/release/dmenv
        asset_name: dmenv-linux

   - name: Upload release assets for macos
      if: matrix.os == 'macos-latest'
      uses: actions/[email protected]
       # similar to upload assets for linux
        
   - name: Upload release assets for windows
      if: matrix.os == 'windows-latest'
      uses: actions/[email protected]
      # ditto

The problem is that upload-assets needs an upload-url and that create-release can only be run once.

If I skip it, there's no upload_url and the artifact cannot be upload.
If I don't skip it, there's an error and only one over 3 artifacts gets uploaded.

I've also tried to run create-release is a separate job, but then I don't know how to access the upload_url in the second job.

Any ideas?

Tracking issue for grcov Action

As in https://github.com/mozilla/grcov

Caching tracking issue

There are two things that can be improved with caching added:

1. Cache target/ and Cargo folders (see an example)
2. Cache the compiled binary from the cargo install {pkgid} command

Right now this affects the following workflows:

• actions-rs/cargo with use-cross: true input enabled (cross is compiled on each call)
• actions-rs/tarpaulin#1
• #20
• #13
• #11
• #5

This issue can be solved by a proper implementation of the actions-rs/core/Cargo.installCached function, see actions-rs/core#31, but it is blocked by actions/cache#55

Right now this issue acts only as a tracking issue for a possibility of proper caching implementation.

cargo audit check

As the Github vulnerabilities scanner does not support Rust yet, it would be worth to add an Action which runs https://github.com/RustSec/cargo-audit and fails CI if there are any vulnerabilities.

fuzz action

Motivation

How much fuzzing is the right amount? Idk, but given that you can't have too much of a good thing maybe we should have a little fuzzing with each commit. (I'm assuming it will start at a different seed each time). If it finds anything then we can add it to the standard test suite.

Workflow example

cargo fuzz run fuzz_me -- -max_total_time=20s

Thoughts? Thumbs up / down?

Advatages

If there's a real clanger of a bug that we've just introduced then a little fuzzing might well pick it up straight away.
And over time it might find those long tail bugs.

Disadvantages

Chews threw a bit of CI minutes.

[question] How to use different features on different toolchains?

I was trying to setup CI using gt actions (for the start I copy-pasted matrix example) and ran into a problem.

For my nightly and stable build I need different cargo-features (like --features "a" and --features "stable a") for all commands (build, test, fmt, clippy).

How can I do that? Maybe it's possible to change env depending on toolchain and then use paste env into commands?

Tracking issue for Tarpaulin Action

As in https://github.com/xd009642/tarpaulin

Support `working-directory`

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about feature requests: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#feature-requests
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Motivation

Other github actions support a working-directory attribute that changes the directory before running any command. actions-rs should do that too. For example, trying to do cargo build --feature=XXX in a workspace won't work; the --feature= switch doesn't work in workspaces. Instead, you must cd into an individual crate to build it with specified features.

Workflow example

    - name: test-with-XXX
      uses: actions-rs/cargo@v1
      working-directory: my_subcrate
      with:
        command: test
        args: --features=XXX

setup sccache action

On CircleCI I make use of sccache on Debian and Windows and it speeds up my builds significantly.

sccache is a RUSTC_WRAPPER that supports caching crates across builds to a on-disk cache that can be limited in size.

I install it on Linux like: https://github.com/artichoke/artichoke/blob/95a94f82326561914e27aac9c14f606aed01c8b1/.circleci/config.yml#L18-L26

and on Windows like: https://github.com/artichoke/artichoke/blob/95a94f82326561914e27aac9c14f606aed01c8b1/.circleci/config.yml#L56-L63

The cache is restored at the beginning of a build like: https://github.com/artichoke/artichoke/blob/95a94f82326561914e27aac9c14f606aed01c8b1/.circleci/config.yml#L137-L139

and saved at the end of a build like: https://github.com/artichoke/artichoke/blob/95a94f82326561914e27aac9c14f606aed01c8b1/.circleci/config.yml#L158-L162

Auto rustfmt commit action?

On all of our repos we have a CI check that ensures rustfmt has been run and fails the build if it has not, and we are experimenting with changing to use the actions-rs action for just that instead of Travis & Buildkite.

But one thing we've thought about (cc @Jake-Shadle) that may be even better alternative workflow would be a rustfmt action that instead of warning or failing a PR on fmt differences actually just runs cargo fmt and commits & pushes changed files to the PR branch.

How hard would it be to create such an action?

Probably is not the best workflow for everyone, but we typically squash our commits so some occasional "Rustfmt" commits is fine, and nice to not have to do manually and push up on a broken build.

This is mostly a problem because RLS doesn't work in our large projects (EmbarkStudios/rust-ecosystem#8) which makes rustfmt not automatically run in VS Code so formatting on save often doesn't work so code slips in without correct formatting.

Upload `cargo doc` results to the GitHub pages

option to read toolchain from rust-toolchain file

Would be really useful. Otherwise it's manual update labor when upgrading the toolchain.

Action for generating coverage reports

Is there any interest in getting support for an action that can generate code coverage reports? I have a simple thing here[1] based on https://github.com/xd009642/tarpaulin, but it's limited in that it only supports x86 Linux.

I've also had some success with grcov and rustc's profiling capabilities, which may work for other platforms.

I'd be willing to spend a bit of time getting this working.

[1]: example here with workflow.

Are there maintainers?

Note

Sorry, it's not a feature request or a bug report.
It is just for a meta-discussion topic.

Checklists

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about feature requests: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#feature-requests
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Motivation

• the actions-rs organization's GithubActions are very famous for rustaceans.
  • It is used in a lot of rust projects.
• But it seems not to be maintained now.
  • The latest commit of this organization was 2 months ago and it was created from the auto-merge of Dependabot.
  • The latest human-made merge seems made over 2 years ago if I didn't miss commits.
  • There are many security PullRequests but it isn't merged.
    • Because, recently, all dependabots were forced migrate into Dependabot v2(Github Native). It doesn't have auto-merge.
    • Also it means security problems are happening on a lot of rust projects.
• It means, maybe, there is no maintainer?
  • (Are you ok...?Are you alive...?)

Workflow example

no workflow. maybe we need to discuss how to help maintainers.

Additional context

No additional context.

How to handle multiple crates scattered throughout my repo?

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about feature requests: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#feature-requests
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Motivation

I have a monorepo with various languages, rust included, at different levels. I don't see how the actions should be used in this case. My brute force approach is to define a Makefile target that recurses my repo like this,

SUBDIRS = $(dir $(shell find . -name Cargo.toml))
test-rust:
        for dir in $(SUBDIRS); do ( cd $$dir && cargo test --verbose); done

... and then call make test-rust from the GH action, after setting up the environment. This seems hacky.

Workflow example

/shrug -- I'm thinking there should be a --recursive-find-crate sort of option.

Additional context

There are existing discussions around pointing to one particular workspace or crate: #27 and #28 which seem germane but don't solve my problem.

Any advise?

Support for SCCACHE

SCCACHE has experimental Rust support.

Maintenance of audit-check

The last release (and commit to the master branch) was a year ago, and there is at least one issue with security implications that has not received any visible attention from the maintainers: actions-rs/audit-check#163

Should the action be declared unmaintained, or is there hope that someone takes it up?