Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jul 06 08:26
    back2dos closed #147
  • Jul 06 08:26
    back2dos commented #147
  • Jun 15 14:22
    kevinresol labeled #160
  • Jun 15 13:37
    cedx opened #160
  • Jun 07 16:07
    dpomier edited #158
  • Jun 07 08:01
    dpomier ready_for_review #158
  • Jun 05 21:20
    tjrhodes closed #159
  • Jun 05 21:20
    tjrhodes commented #159
  • Jun 05 19:45
    tjrhodes opened #159
  • May 29 15:31
    dpomier synchronize #158
  • May 29 15:28
    dpomier edited #158
  • May 29 15:24
    dpomier opened #158
  • May 25 05:36
    back2dos commented #156
  • May 24 20:10
    PXshadow commented #156
  • May 22 19:38
    cedx edited #157
  • May 22 19:36
    cedx opened #157
  • Apr 23 08:51
    kevinresol commented #152
  • Apr 23 08:45
    RichardBray commented #152
  • Mar 18 22:44
    Gama11 opened #70
  • Mar 07 06:55
    back2dos opened #69
Peter Achberger
@Antriel
I'm gonna try that ssh/https way. Hopefully I figure it out. :D
Kevin Leung
@kevinresol
the idea of git+ssh is that your machine should be able to access all the private repo on is own
and on CI you really want a ssh key without passphrase
Peter Achberger
@Antriel
Yeah that makes sense.
Why without passphrase?
Kevin Leung
@kevinresol
otherwise the CI will prompt for a password
and you have basically no way to input it
Peter Achberger
@Antriel
Right.
I've never setup a CI so far, but something tells me I might need to in in a year or two.
Oh github has deploy keys, I wonder if that will work too.
Kevin Leung
@kevinresol
when you share your repo with some colleagues then you will realize you don't want your credentials tracked
Peter Achberger
@Antriel
Seems to be normal keys, just limited to read access to single repo.
Kevin Leung
@kevinresol
yes that will work
Peter Achberger
@Antriel
Yeah, for sure. I was thinking about that already. Don't need it yet, but probably a good idea to set it up now.
Peter Achberger
@Antriel
Hmm, using https it just asks for password, that's not horrible. But I couldn't get the ssh working. It says FATAL ERROR: Disconnected: No supported authentication methods available (server sent: publickey).
I did add it to the local chain, and I could verify it via ssh -T git@github. Oh, wait...
I was using antriel@github, but seems like that wasn't it either. Still the same error.
Peter Achberger
@Antriel
SSH agent doesn't work from the old windows cmd. :sweat_smile:
Got that working, and I can verify on the cmd, but lix still throws the same error. Hmm.
Peter Achberger
@Antriel
Do I need to somehow configure local git or something? I'm not sure where that error comes from, but ssh -T git@github works, lix install git:git@github.com:Antriel/foo.git does not.
Kevin Leung
@kevinresol
not sure about windows, on mac/linux it is just about generating a key pair (~/.ssh/id_rsa and ~/.ssh/id_rsa.pub) and then upload the public key to github
Peter Achberger
@Antriel
Yeah, did all that, added it to the ssh agent...
Kevin Leung
@kevinresol
tbh I never really know how ssh agent works on windows..
I guess somehow you have to make the process which uses ssh aware of the agent?
Peter Achberger
@Antriel
Hmm...
Kevin Leung
@kevinresol
I vaguely remember I need to make some settings on windows sourcetree so that it knows how to deal with the agent
Peter Achberger
@Antriel
I will google, can't be that difficult.
Probably some local git setting or something.
Peter Achberger
@Antriel
Finally! Git was using its own ssh, I was setting up my openSSL installation... Even though I forced git to use it, it didn't. Even though I set up git's ssh, and it connected successfully, it still didn't work... Ended up just removing git's ssh. WTH.
Philippe
@elsassph
I like to use Travis CI's Haxe images, which is nice to switch between Haxe versions to test a library against different versions. Is it possible to make it work with lix somehow? Could lix work in this case be "passthrough" instead of replacing the haxe executable?
Juraj Kirchheim
@back2dos
if the version in .haxerc looks like a path, then haxeshim will use that
Dan Korostelev
@nadako
Hmm, I'm getting this Updating state in a binding warning. As far as I understand this is to prevent manual dependent state management in favor of Observable.auto, which is totally fine.
But I think I have a situation where it's not really possible and it actually seems fine to do updates like that. I have of course to think about this some more, but in the meantime - is there a way to avoid this warning? Maybe scheduling the update somehow or something?
Kevin Leung
@kevinresol
define yourself as naughty:
-D tink_state_ignore_binding_cascade_because_I_am_a_naughty_naughty_boy
Dan Korostelev
@nadako
but i don't want to:) i want this warning in general, i just don't want in this specific case
Juraj Kirchheim
@back2dos
things run within Scheduler.atomically don't produce the warning
although I'm not so sure that's such a good idea ^^
Dan Korostelev
@nadako
wait why i'm asking in the lix channel, damn :)
Philippe
@elsassph
Changed my mind, Travis can go to hell.
But your tip, @back2dos, seems to work.
Philippe
@elsassph
image.png
oook
Juraj Kirchheim
@back2dos
huh, what's that? ^^
Philippe
@elsassph
Trying to npx lix install haxe XXX in a Github action (with Node)
Juraj Kirchheim
@back2dos
why 3.5.7? :D
Philippe
@elsassph
oooh
Juraj Kirchheim
@back2dos
Is that a typo or an internal build?
Philippe
@elsassph
No it's a typo...
let me try again with 3.4.7 :D
Not a very helpful error message when you ask for a non-existent version :D
Juraj Kirchheim
@back2dos
yeah, it's weird indeed