These are chat archives for fiji/fiji

11th
Jan 2019
turekg
@turekg
Jan 11 13:28
@ctrueden did you ever try to set up an automated project board in GitHub (https://help.github.com/articles/about-automation-for-project-boards/) It seems like it would be a very nice way to have a first glance overview for “imagej” and “Fiji” development (can have more than one project) By controlling which repos are connected to a “project” you basically have a card per issue, and I would expect to be able to see duplicates quite readily. Unfortunately I can’t really test this out with the juglab organization repos because there there is no “project” there to speak of. It’s the automation that makes this more attractive than waffle.io. I am speaking of course with my devops hat on, not from a coder point of view. It seems to me waffle.io is more of a project management tool.
@ctrueden I am still not being able to get a successful build of juglab/imagej-updater. It seems to be connected to the fact that there are still global variables present in the travis.yml config (given that I can build & test on my laptop, though there I am just invoking compile and test) Perhaps I should just remove the remaining env variables….
turekg
@turekg
Jan 11 14:30
@ctrueden yep, all global encrypted vars had to be removed. Makes no sense to have them there anyways if they are not the correct ones
Curtis Rueden
@ctrueden
Jan 11 14:56
@turekg I never tried GitHub Projects because it is not cross-organization. But I suppose we could live with one board per organization.
@turekg Regarding the Travis build of a fork: yeah, those env vars will not be correct for the fork.
Because I think they are hashed somehow on the repo slug.
You can either: A) remove the env vars; or B) change the GAV of the artifact(s) in the fork, and then regenerate the env vars using travisify.sh. To do (B) you need the credentials files; I believe @tpietzsch and/or @fjug have copies.
The reason to do (B) is to get your Travis builds deploying some build artifacts to maven.imagej.net. Which you might not need.
Are you building just to test for regressions? Or to make artifacts available downstream? Probably just the former, no?
turekg
@turekg
Jan 11 15:22
@ctrueden Just want to build and test for regression on the forks, makes more sense than waiting for pull requests and subsequent tests
Yes, removing all the env vars worked perfectly.
Curtis Rueden
@ctrueden
Jan 11 17:17
:+1: