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
CI: add job to run tests with ant
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
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
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
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
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