Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

kick the tires on GitHub actions #1564

Open
wants to merge 9 commits into
base: master
from

Conversation

@softprops
Copy link
Contributor

softprops commented Oct 27, 2019

Please help keep the CHANGELOG up to date by providing a one sentence summary of your change:

experiment with #1553

@softprops

This comment has been minimized.

Copy link
Contributor Author

softprops commented Oct 27, 2019

hrm not seeing anything in the actions tab typically when I'm setting these up I see the workflow registered within a few seconds the first time I'm registering a workflow

@softprops

This comment has been minimized.

Copy link
Contributor Author

softprops commented Oct 27, 2019

leaving a note while I try to get this working that GitHub actions also support badges in the form https://github.com/{owner}/{repo}/workflows/{workflow_name}/badge.svg in the case of this example https://github.com/rusoto/rusoto/workflows/CI/badge.svg

@softprops

This comment has been minimized.

Copy link
Contributor Author

softprops commented Oct 28, 2019

so interestingly I am seeing actions run but on my fork https://github.com/softprops/rusoto/runs/276916243 this may be somewhat of a caveat for initially setting up actions from a remote fork for the first time.

current status the unit tests are failing for me on cargo +$RUST_VERSION test --all -v --no-default-features --features=rustls with the following

Screen Shot 2019-10-27 at 8 08 10 PM

I'll dig in a bit more and get this pull posted

@softprops

This comment has been minimized.

Copy link
Contributor Author

softprops commented Oct 28, 2019

just a heads up the same also fails on azure pipelines but failures are ignored in these cases https://dev.azure.com/matthewkmayer/Rusoto/_build/results?buildId=399&view=logs&jobId=e5cb303c-39a7-59b4-a035-10c1c587ea3c

@softprops

This comment has been minimized.

Copy link
Contributor Author

softprops commented Oct 28, 2019

looks like that's already the radar. I just noticed the open issue for this in #1548

@matthewkmayer

This comment has been minimized.

Copy link
Member

matthewkmayer commented Oct 28, 2019

Thanks for experimenting with this!

#1557 should address the nightly builds issue, just needs some eyes on it for review. 😄

Copy link
Contributor

itsHabib left a comment

LGTM

@softprops softprops force-pushed the softprops:github-actions branch from 214dece to 759ef96 Oct 29, 2019
@softprops

This comment has been minimized.

Copy link
Contributor Author

softprops commented Oct 29, 2019

Hitting some no space left on device errors now.

GitHub documents 14 gigs. I'll do a little more experimenting.

@softprops softprops force-pushed the softprops:github-actions branch from 759ef96 to 8265350 Nov 2, 2019
@matthewkmayer

This comment has been minimized.

Copy link
Member

matthewkmayer commented Nov 5, 2019

Got a particular spot you'd like reviewed?

I saw the notice about build badges. Does crates.io support github actions as a build badge?

Looking forward to getting this working to address various shortcomings of the current build pipeline. 😻

@softprops

This comment has been minimized.

Copy link
Contributor Author

softprops commented Nov 5, 2019

main blocker atm are these disk space errors I've yet to work around.

   Compiling rusoto_ec2 v0.41.0 (D:\a\rusoto\rusoto\rusoto\services\ec2)
   Compiling rusoto_xray v0.41.0 (D:\a\rusoto\rusoto\rusoto\services\xray)
   Compiling rusoto_cur v0.41.0 (D:\a\rusoto\rusoto\rusoto\services\cur)
   Compiling rusoto_kafka v0.41.0 (D:\a\rusoto\rusoto\rusoto\services\kafka)
LLVM ERROR: IO failure on output stream: no space on device
error: could not compile `rusoto_kafka`.
warning: build failed, waiting for other jobs to finish...
error: failed to write d:\a\rusoto\rusoto\target\debug\deps\rmetac5dBhp\rust.metadata.bin: There is not enough space on the disk. (os error 112)

re crates.io badge not yet

@softprops softprops force-pushed the softprops:github-actions branch from 53bbb48 to 8528f05 Nov 16, 2019
@iliana

This comment has been minimized.

Copy link
Member

iliana commented Jan 9, 2020

main blocker atm are these disk space errors I've yet to work around.

I can look into setting up infrastructure for a self-hosted runner: https://help.github.com/en/actions/automating-your-workflow-with-github-actions/about-self-hosted-runners

We have this cloud thing that has plenty of storage. :) Would that help unblock, @softprops?

edit: ... although EC2 could only do Linux and Windows, so we'd still want to fix the disk space issue for macOS.

@lnicola

This comment has been minimized.

Copy link

lnicola commented Feb 9, 2020

If you can afford it, turning down the debug info level can greatly reduce the disk space required.

@pietroalbini

This comment has been minimized.

Copy link

pietroalbini commented Feb 9, 2020

I can look into setting up infrastructure for a self-hosted runner:

I wouldn't do that: https://help.github.com/en/actions/automating-your-workflow-with-github-actions/about-self-hosted-runners#self-hosted-runner-security-with-public-repositories

main blocker atm are these disk space errors I've yet to work around.

You could try running builds in the C: partition. A df -h in a Windows builder outputs:

Filesystem            Size  Used Avail Use% Mounted on
C:/Program Files/Git  256G  125G  131G  49% /
D:                     14G  1.8G   13G  13% /d
@iliana

This comment has been minimized.

Copy link
Member

iliana commented Feb 9, 2020

I wouldn't do that: https://help.github.com/en/actions/automating-your-workflow-with-github-actions/about-self-hosted-runners#self-hosted-runner-security-with-public-repositories

There are ways to securely run runners. My plan was an autoscaling group and the --once option to recycle an EC2 instance for every job. The newly announced Actions API makes that a little easier too.

@CleanCut

This comment has been minimized.

Copy link

CleanCut commented Feb 10, 2020

You could try running builds in the C: partition.

👍 😉

@softprops

This comment has been minimized.

Copy link
Contributor Author

softprops commented Feb 10, 2020

I had an idea that I've not yet exercised in fully beyond some a game of bash golf and cargo metadata mining https://gist.github.com/softprops/5c0566c12ba26b2d9efcbb5c1ca62f29

I believe that each job is a vm and each vm holds the limits on amount of disk used. The theory here is that if we were to partition a job like "test" into n number of parts we might be able to whittle down the disk space used into something that fits more comfortably in GitHub actions

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

7 participants
You can’t perform that action at this time.