Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Connor Kuehl
    @connorkuehl
    can we define one like that
    Harald Hoyer
    @haraldh
    #[cfg(not(__my_macro_name_undefined_cfg = ""))]
    if it has to be cfg.. @npmccallum say something :)
    Nathaniel McCallum
    @npmccallum
    It doesn't.
    @haraldh I'm currently using your first suggestion.
    Harald Hoyer
    @haraldh
    good :)
    Harald Hoyer
    @haraldh
    rust turned 5
    Connor Kuehl
    @connorkuehl
    same
    Harald Hoyer
    @haraldh
    hehe
    Lily Sturmann
    @lkatalin
    lol
    Mark Bestavros
    @mbestavros
    @npmccallum I have very positive news re. the runner: the public image (https://github.com/joeyx22lm/docker-github-actions-runner) should work exactly as we need it to, as long as we can store a Github-provided token securely on the Packet server.
    Nathaniel McCallum
    @npmccallum
    @mbestavros That shouldn't be a problem. Just get it into the kickstart and we should be good to go!
    Mark Bestavros
    @mbestavros
    In other words, if the container stops, we can invoke the same command (with the same token) after a reboot to restart the same runner, with the same name. We shouldn't need any manual interaction apart from initially provisioning the token.
    Nathaniel McCallum
    @npmccallum
    That's great!
    Mark Bestavros
    @mbestavros
    I'm looking at the kickstart now!
    Mark Bestavros
    @mbestavros
    @npmccallum I'm forgetting... is there a way to provide input/arguments to the kickstart? Not just for the token, but also for runner names...
    Nathaniel McCallum
    @npmccallum
    Yes and no.
    Don't worry about it.
    Just presume the token is in a file on the disk somehow.
    Mark Bestavros
    @mbestavros
    Presume the same for runner name?
    heh that rhymed
    Nathaniel McCallum
    @npmccallum
    Yes.
    Mark Bestavros
    @mbestavros
    Great. I'll submit a PR very soon then!
    Mark Bestavros
    @mbestavros
    @npmccallum @haraldh enarx/packet.com#10
    Nathaniel McCallum
    @npmccallum
    @haraldh Can you touch this? enarx/enarx#537
    Lily Sturmann
    @lkatalin
    @connorkuehl Do we know that we can set env variables for cargo make as part of a task?
    I can basically bake a path into a "script" value with bash but can't assign it as its own cargo make env var unless I do it outside a task
    Harald Hoyer
    @haraldh
    @npmccallum done
    Lily Sturmann
    @lkatalin
    Actually it looks like it's possible to set env vars in tasks with Duckscript
    Lily Sturmann
    @lkatalin
    And a few other ways
    @lkatalin reads all the docs
    Nathaniel McCallum
    @npmccallum
    @connorkuehl SGX v30 is out. But don't build it. It only contains documentation changes. v31 should be out shortly.
    Harald Hoyer
    @haraldh
    @npmccallum @connorkuehl I have a small PR for you :grin: enarx/enarx#542
    Nathaniel McCallum
    @npmccallum
    @haraldh Ditto! enarx/enarx#541 :)
    Harald Hoyer
    @haraldh
    An unexpected error occurred when executing this workflow. Please submit a new support request using our Support website:
    
    https://support.github.com/contact
    
    Please include this unique ID in your request: 3E09:14F5:1AE197:1CCCFE:5EBEFC75
    meh
    @npmccallum oh my... looks like I have to expand the macros with cargo expand...
    @npmccallum we can't test, that something doesn't compile, or can we?
    Nathaniel McCallum
    @npmccallum
    @haraldh I wondered the same thing...
    Harald Hoyer
    @haraldh
    very cool
    yeah, I should add more doc tests
    at least for the parts, which don't rely on kvm
    Harald Hoyer
    @haraldh
    my PR is cursed... the CI won't run all tests
    ah.. rebase might fix it
    now we are talking
    Lily Sturmann
    @lkatalin
    @connorkuehl Totally fine if you reply to this on Monday, but do you have insight as to why you need both workspace = false and condition = { env_not_set = ["CARGO_MAKE_CRATE_NAME"]} to create a top-level task? I would expect it to work with just the former. However, as I'm testing, having only workspace = false does nothing and adding the env var not set condition means the task is skipped entirely at the crate level and top level.
    Connor Kuehl
    @connorkuehl
    @lkatalin hmm, I checked my notes and I think I ran into the same thing with the include_members -- I think we should file a bug with upstream cargo-make. If you're just about to head into your weekend I can make a reproducer and file it with the upstream developer
    Lily Sturmann
    @lkatalin
    @connorkuehl I'm going to work on this a bit longer, but I also trust myself less not to just be doing something dumb with cargo make since I'm only partway through the docs