Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    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...
    https://doc.rust-lang.org/edition-guide/rust-2018/rustdoc/documentation-tests-can-now-compile-fail.html
    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
    Connor Kuehl
    @connorkuehl
    @lkatalin no worries! If I don't hear back from you in a couple hours I'll file a bug upstream, because my notes corroborate your experience and I think I did the condition to help work around it. The upstream dev might also patch it by Monday; they are very quick
    Lily Sturmann
    @lkatalin
    @connorkuehl I love that they have a quick turnaround
    Hmmmmm
    I think I'm sort of blocked until this part makes sense. My next step would actually be to make a minimal version that doesn't work as a sanity-check. Maybe that would be useful to the bug report.
    Connor Kuehl
    @connorkuehl
    @lkatalin Okay! Yeah, I would make a git repo and just make two crates, then make a root-level Makefile.toml that enables workspace emulation -- then make a task that sets CARGO_MAKE_WORKSPACE_INCLUDE_MEMBERS = "crate-a" or something and have it run an echo hello world or something. Then it should be clear to the developer that CARGO_MAKE_WORKSPACE_INCLUDE_MEMBERS doesn't work as intended with workspace emulation when hello world is emitted for both crates in the workspace rather than just the one we specified to include
    Lily Sturmann
    @lkatalin
    @connorkuehl Good idea - that's basically what I've been doing in the Enarx repo anyway haha (I commented out a bunch of the workspace members, etc.)
    I'll send a message when I've made the repo
    Lily Sturmann
    @lkatalin
    @connorkuehl I think this actually has something to do with it: "This flag (workspace=....) is only checked for the task on the cargo-make command line and is completely ignored for all other tasks which are executed as part of the flow." It'll work properly if I'm not calling it as part of another task or flow.
    OMG I think we have to fork