#ls2 (irc2p) | #ls2 I2P Protocol Development Discussion - Next Meeting Monday, October 9th 6:30 UTC

zlatinb I added github actions CI build for muwire. If we had the same for i2p it would be easy for people to get nightly builds

zlatinb eyedeekay: ^^

zlatinb it was really easy, see .github/workflows/gradle.yml in the mw source tree

zlatinb but someone with github admin rights should do it to make sure it's done right

zlatinb i2pd has those too, see their .github/workflows dir for several platform-specific yml files

zlatinb and looks like there is an ant workflow ready to be used docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-java-with-ant

zlatinb maybe because ant is part of ubuntu..?

orignal more questions are coming

zlatinb eyedeekay, zzz: MR !53 for github actions

zzz zlatinb, eyedeekay would this be better done on gitlab, where we would have more control over notifications?

zlatinb it can be done on both independently

zzz sure, but why both?

zlatinb I imagine the gitlab CI config goes in .gitlab whereas the github yml goes in .github

zlatinb more ppl visit github I guess

zzz but nobody needs the CI result except us

zlatinb the CI result is an installer.jar, anyone may want to use it

zlatinb there can be other results too ofc, like code coverage

zzz there's a whole UI in gitlab for setting up CI

zlatinb but in the MR so far I have only configured an installer.jar upload

zzz ideally we get back to a bot in #i2p-dev that hollers when the CI fails, like we used to have long ago

zlatinb should be possible

zlatinb I mean it definitely is possible, may require coordination with ech/postman

eyedeekay I've got a lot of build related stuff I want to work on this weekend, I can make that happen again while I'm at it

zlatinb gitlab yaml syntax is a bit different, I'm looking at it now

zzz imho the main goal of CI is rapid notification of failure. Binary installers/updaters is a lot farther down the list, if needed at all

zlatinb idk, costs us nothing really and it's an easy way for users to grab the latest code

zzz zlatinb, drzed has a .gitlab-ci.yml in i2p+

zlatinb I'll try and write one for muwire first, maybe with code coverage and whatnot

zzz eyedeekay, I assume our gitlab has enough CPU and memory for this?

eyedeekay For just us it should be fine, I'll make it so only our accounts/groups get to use it

eyedeekay To prevent a spammer from trying to use it as a way to exhaust the server or run up my bill

eyedeekay If it turns out to be too big a deal I'll move the CI to it's own box someplace else

zzz actually, we have a .gitlab-ci.yml in our tree as well

zzz last touched by eyedeekay a year ago

eyedeekay It should still work but the runners have been timing out, that's part of what I was going to work on this weekend

zzz Date: Mon Feb 22 13:16:19 2021

zzz Merge branch 'ci-ant-test' into 'master'

zzz

zzz CI: add job to run tests with ant

zzz

zzz See merge request i2p-hackers/i2p.i2p!21

zlatinb "Job is stuck. Check runners"

eyedeekay I don't think the problem is on the .gitlab-ci.yml side, the service that runs the CI is a separate container and that container is failing to communicate with the gitlab container, which it used to do correctly.

eyedeekay My plan is to tear down the old CI container and re-build it again from scratch

zlatinb yeah it's saying something about no runners available

eyedeekay Yeah I'm not sure what broke it and I keep blowing weekends trying to figure it out, so it's getting burned to the ground and rebuilt

eyedeekay zlatinb do you know why I would have to do this:

eyedeekay ClientAppManager cam;

eyedeekay while ((cam = ctx.clientAppManager()) == null) {

eyedeekay sleep(1000);

eyedeekay }

eyedeekay In my REGISTER_UPP thread when you apparently don't?

zlatinb idk lol

eyedeekay If I don't do that then sometimes I end up calling getRegisteredApp on a null CAM which messes things up and it seems weird to me that it doesn't happen to you also

zlatinb hmm, maybe it does happen in the field but I'm just not aware of it

zlatinb what about the RouterContext, do you wait for that?

eyedeekay Sure do, I actually copied my version of the thread from yours to start with, except for that section and variable names they are identical

zlatinb maybe I should wait for it too

eyedeekay Seems like it might be safer if you do, but I have no idea of the cause

eyedeekay Some obscure race of some sort. I think I ran into another one of those not-useful hashes when it threw the NPE, something called <local1>

eyedeekay Which I guess is how it was labeling the reference to the null object if I interpreted the error correctly

zzz yes there is a small window where the context exists but has not been initialized

zzz I believe I recommended an alternate startup method, Router r = new Router(...); r.runRouter(); ctx = r.getContext()

zzz rather than RouterLaunch

zzz that will let you remove all but the last sleep()

zzz iirc zlatinb said he was happy with it as-is since it worked :)

zlatinb iirc I chose RouterLaunch in order to make sure the loading of properties and config files happens exactly the same way as in the old installers

eyedeekay OH that explains the reason I didn't see it before as well, I was using runRouter before I started messing with my broken updates, I switched back to RouterLaunch to simplify what I was looking at

zzz yeah but RouterLaunch just calls Router.main() which just checks for an i2pupdate.zip (that you'll never have) and then does new Router, runRouter()

zzz so it's no difference

zlatinb ok, may change it at some point

eyedeekay zlatinb would you object to re-creating your MR as a PR on github? I'm not sure there's another way to trigger the action on the branch

zlatinb sure, as long as it propagates correctly back to gitlab

eyedeekay Should be fine, worked last time. I'll keep my eye on the sync though

zlatinb eyedeekay: github.com/i2p/i2p.i2p/pull/26

zlatinb oh, I get to test it now

zlatinb lets see why it borked

zlatinb which debian package is msgfmt found in? Or if we don't care can I disable the bundle target?

zlatinb gettext

zlatinb so how do we fixx0r this

eyedeekay Hopefully there's a place we can specify additonal dependencies, I see ubuntu-latest in the file itself, ideally we should be able to just specify the package

eyedeekay stackoverflow.com/questions/57982945/how-to-apt-get-install-in-a-github-actions-workflow

eyedeekay Looks like we get to just sudo apt-get install gettext

eyedeekay In a run: line

zlatinb yeah just tried it, worked

zlatinb but now it couldn't find installer.jar

zlatinb wtf

R4SAS :D

R4SAS github.com/PurpleI2P/i2pd/blob/openssl/.github/workflows/build.yml#L15-L19

zlatinb oh, it's install.jar

R4SAS isn't it easier how neighbours done it? ))

R4SAS easier to see *

zlatinb java is "special"

R4SAS if you'll watch a bit lower, you'll wee how to build packages too

R4SAS just as reference

zlatinb github.com/zlatinb/i2p.i2p/actions/runs/1831235354 # worked

zlatinb ofc the artifact is zipped automatically so the user has to unzip to get the install.jar

zlatinb but that should be ok

R4SAS yes... that's only problem with gha artifacts

eyedeekay Good I see it, thanks zab

eyedeekay Useful piece of information to have about the zipped artifacts

R4SAS and one more problem

R4SAS aftifacts available only for autheticated users

zlatinb that's not cool

zlatinb but better than nothing I guess

R4SAS guests not authorized on gh cant download them

eyedeekay We could work around that by pushing the results to the releases section and just tag them all `pre-release`

zlatinb some tips on doing that trstringer.com/github-actions-create-release-upload-artifacts

eyedeekay Do you want to add them on your PR or should it be a separate one?

zlatinb separate is better

zlatinb I'm not ready to do things with tokens and secrets and all that advanced devops stuff :)

eyedeekay Ack. In that case I'll merge your existing PR now as long as you're ready

zlatinb yeah, it's a good first step I think

eyedeekay OK

zlatinb do we really want to have a release for each push though? Even if we tag them as pre-releases... don't know

eyedeekay1 As long as it's github's storage and we make it clear in the title/description that they are built as part of CI and not releases, I'm fine with it

zzz i think it's too much