Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 01 19:39

    killercup on gh-pages

    Deploy rust-lang-nursery/cli-wg… (compare)

  • Oct 01 19:34
    Dylan-DPC synchronize #58
  • Oct 01 19:34

    Dylan-DPC on master

    Fix typos in README of survey-r… (compare)

  • Oct 01 19:34
    Dylan-DPC closed #145
  • Oct 01 18:03
    JohnTitor opened #145
  • Oct 01 17:54
    JohnTitor opened #144
  • Oct 01 17:11

    killercup on gh-pages

    Deploy rust-lang-nursery/cli-wg… (compare)

  • Oct 01 17:05
    Dylan-DPC synchronize #58
  • Oct 01 17:05

    Dylan-DPC on master

    Remove Gitter from README (#143) (compare)

  • Oct 01 17:05
    Dylan-DPC closed #143
  • Oct 01 17:05
    Dylan-DPC commented #143
  • Oct 01 17:02
    JohnTitor opened #143
  • Sep 18 15:26
    lzutao opened #142
  • Sep 10 06:48
    ashutoshrishi commented #33
  • Aug 26 12:49

    killercup on gh-pages

    Deploy rust-lang-nursery/cli-wg… (compare)

  • Aug 26 12:45
    Dylan-DPC commented #141
  • Aug 26 12:45
    Dylan-DPC synchronize #58
  • Aug 26 12:45

    Dylan-DPC on master

    Fix fuzzing broken link (#141) (compare)

  • Aug 26 12:45
    Dylan-DPC closed #141
  • Aug 26 12:45
    Dylan-DPC closed #140
Jacob Finkelman
@Eh2406
I thought someone hare may have some advice.
Daniel Sockwell
@codesections
I wish I did, but I haven't faced that particular challenge—or even built pre-compiled binaries yet. But I'm interested to hear what answers you might get.
and cargo-sweep sounds like an interesting tool; glad I learned about it by following your link :)
Ed Page
@epage
@Eh2406 sorry I missed that I was tagged in it
What specific problem are you having with trust atm?
Jacob Finkelman
@Eh2406
It looks like it did not make prebuilt binaries with the release, as such we did not succeed at using the install script
So we messed up one or the other of setting up trust or using the install script
Ed Page
@epage
Yeah, trust is not my favorite but there isn't better yet
I keep pushing off cargo-tarball for other things; I really need to set aside some time to implement it
Would take away some of the trust boilet plate
Jacob Finkelman
@Eh2406
here is a simple test of the install script https://travis-ci.org/Eh2406/cargo/jobs/484542914#L621-L631
Ed Page
@epage
Not seeing any output from your before_deploy. Looking at your deploy, I see on: tags: true but I'm not seeing any tags in your travis history
https://travis-ci.org/holmgr/cargo-sweep/builds
Yeah, install.sh assumes the binary will be available at https://github.com/holmgr/cargo-sweep/releases which is what trust deploys to.
So you can just look at that page to see whether it is install.sh or your CI setup
Jacob Finkelman
@Eh2406
So you're working hypothesis is @holmgr made the release in the wrong way?
Ed Page
@epage
Not wrong, just missing a step (tagging). You can tag after the fact
Jacob Finkelman
@Eh2406
Ed Page
@epage
Oh, you're right
"/^v\\d+\\.\\d+\\.\\d+.*$/".travis.yml is only configured for tags that start with v.
So either changing .travis.yml or adding a new tag v0.4.0 should get it kick started
Jacob Finkelman
@Eh2406
so changing that line to "/^v?\\d+\\.\\d+\\.\\d+.*$/" will make it work?
Ed Page
@epage
For future tags, yes
Jacob Finkelman
@Eh2406
I do not have permissions on the repo, to test myself, but do you have instructions for how to trigger a build on the existing release?
Ed Page
@epage
If the build existed, you'd see a rebuild button
but for a tag that it ignored, I have no idea
Jacob Finkelman
@Eh2406
Ok, thanks for all the help!
Ed Page
@epage
Like I said, you could always re-tag the commit with v0.4.0 and then travis will pick it up
Ed Page
@epage
Ah, it assumes v as well
Jacob Finkelman
@Eh2406
does that mean that the name needs to start with a v for install to work
Ed Page
@epage
Yup
Jacob Finkelman
@Eh2406
ok closing my pr.
Ed Page
@epage
It has to know what tags are relevant
Jacob Finkelman
@Eh2406
I closed my pr to cargo sweep holmgr/cargo-sweep#21
Jacob Finkelman
@Eh2406
I don't have perms, so hopefully @holmgr can retag things this weekend, and we will see if it is fully working.
Jacob Finkelman
@Eh2406
set up travis on my fork, and pushed a tag: https://github.com/Eh2406/cargo-sweep/releases/tag/v0.4.0
Jacob Finkelman
@Eh2406
It picked up the tag and tried to deploy but it has his secrets, so it did not work.
https://travis-ci.org/Eh2406/cargo-sweep/jobs/484559290#L267
https://travis-ci.org/Eh2406/cargo-sweep/jobs/484559285#L647
So it looks like changing the tags will work.
Thanks for the help!
Ed Page
@epage
You're welcome
Ed Page
@epage
RE assert_cmd 1.0
This is in the works.
I've been letting it sit to gather feedback before bumping to 1.0. This led to assert-rs/assert_cmd#69 and am in that same holding pattern; waiting for people to upgrade, try it out, and report back problems

assert_fs is in a similar boat but less controversial in my mind; I'd be willing to bump that any time.

Should they both go in the same announcement post?

Pascal Hertleif
@killercup
@epage morning! yeah, wanted to ping you about that. at the all hands cli meeting yesterday we talked about assert-rs for a bit -- it's probably the most complete of all the items we had on the WG todo list from last year!
Pascal Hertleif
@killercup
what are your immediate plans for these crates? i haven't been following in detail, but _cmd and _fs both look like there are no breaking changes happening soon, right? if we can squish the last known bugs, pushing them to 1.0 sounds like a good idea.
i'd love to get one or more blog posts out explaining to people how these crates fit together and how amazing predicates is. i can totally (help) write this
this might also be the right time to make assert_cli re-export the 1.0 crates, as well as helpers like tempfile
Ed Page
@epage
I would put them at release candidate stage (and have been for a while). I've taken care of any 1.0 blocking bugs but I consider the recent API breakers to be uncertain enough that I was planning on waiting a month or so to see what feedback trickles in.
So the current plan for assert_cli is to just aggregate the various CLI-related testing crates? At one point you were talking about a higher level, abstraction like in the waltz tests
Oh and two things I'd like to see but not blocking 1.0
  • Directory diffing. Still been mulling over what'd be the appropriate API
  • Snapshot testing as you suggested. I'm waiting to see how the other snapshot testing crates mature
Katharina
@spacekookie
:wave: