actions-rs / meta Goto Github PK
View Code? Open in Web Editor NEW๐ฆ GitHub Actions for Rust - recipes, discussions, questions and ideas
Home Page: https://github.com/actions-rs
License: Creative Commons Zero v1.0 Universal
๐ฆ GitHub Actions for Rust - recipes, discussions, questions and ideas
Home Page: https://github.com/actions-rs
License: Creative Commons Zero v1.0 Universal
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.
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.
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).
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!
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.
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.
@yaahc proposed an idea to add Action with semverver tool.
So far there are two possible options to use it:
*-check
Actions, execute it on: [push, pull_request]
and add check annotations with the compliance notes.release: published
event (idea goes to @yahhc) and fail the check for it if there were any compliance issues.Unresolved questions:
Patch
, NonBreaking
, TechnicallyBreaking
, and Breaking
); how should the check act at all?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?Any ideas and suggestions will be much appreciated!
I'd love to see support for the new source-based profiling as an action, similar to grcov
and tarpaulin
actions.
See https://blog.rust-lang.org/inside-rust/2020/11/12/source-based-code-coverage.html
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.
I pretty much copied the Matrix example: https://github.com/jjant/runty8/pull/27/files#diff-73e17259d77e5fbef83b2bdbbe4dc40a912f807472287f7f45b77e0cbf78792d
Use https://github.com/est31/cargo-udeps to check if all dependencies are used
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.
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?
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:
Hi ! Thanks for all the actions :)
Would be amazing to have a release
action that would
https://github.com/sunng87/cargo-release does most of the above
What do you think ?
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.
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:
To name a couple of options.
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:
dmenv.exe
on Windows, dmenv-osx
and dmenv-linux
on the 3 matching operating systemsHere'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?
There are two things that can be improved with caching added:
target/
and Cargo folders (see an example)cargo install {pkgid}
commandRight now this affects the following workflows:
actions-rs/cargo
with use-cross: true
input enabled (cross
is compiled on each call)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.
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.
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.
cargo fuzz run fuzz_me -- -max_total_time=20s
Thoughts? Thumbs up / down?
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.
Chews threw a bit of CI minutes.
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?
Do the checklist before filing an issue:
actions-rs
Actions?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.
- name: test-with-XXX
uses: actions-rs/cargo@v1
working-directory: my_subcrate
with:
command: test
args: --features=XXX
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
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.
Would be really useful. Otherwise it's manual update labor when upgrading the toolchain.
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.
Sorry, it's not a feature request or a bug report.
It is just for a meta-discussion topic.
Do the checklist before filing an issue:
actions-rs
Actions?actions-rs
organization's GithubActions are very famous for rustaceans.
no workflow. maybe we need to discuss how to help maintainers.
No additional context.
Do the checklist before filing an issue:
actions-rs
Actions?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.
/shrug -- I'm thinking there should be a --recursive-find-crate sort of option.
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?
SCCACHE has experimental Rust support.
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?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.