-
Notifications
You must be signed in to change notification settings - Fork 161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[INFRA] Run linkchecker in stock docker image #932
Conversation
The linkchecker is now failing because https://thewinnower.com is down. |
sounds good because then it works :-) thanks! |
@@ -9,19 +9,19 @@ | |||
# for instructions | |||
|
|||
# tag for patched linkchecker -- will also serve our image version | |||
version="9.4.0.anchorfix1" | |||
version="v10.0.1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just FTR: properly (?) fixed in linkchecker/linkchecker#462 (issue linkchecker/linkchecker#460) which was v10.0.0~14^2
(thus this version above includes it) instead of my adhoc linkchecker/linkchecker#194 (which I believe was what that version pointed to).
.circleci/config.yml
Outdated
@@ -21,7 +21,7 @@ jobs: | |||
|
|||
linkchecker: | |||
docker: | |||
- image: yarikoptic/linkchecker:9.4.0.anchorfix1-1 | |||
- image: markiewicz/linkchecker:v10.0.1-1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we may be just establish bids
or bids-specification
docker hub org? (otherwise we would just keep footballing it across private orgs)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a bids
, but it's maxed out in users. Guess we could create a bids-maintenance
one for things like this, as we did with Zenodo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but it's maxed out in users
looks like we can have 3 users for a free-plan dockerhub org. As long as these three are also BIDS maintainers, I think that sufficiently minimizes the bus factor, so I'd rather we check and redistribute the "members" of current bids
dockerhub than creating a new bids-maintenance
dockerhub org (which would also be fine, but not preferred from my side)
https://www.docker.com/blog/how-to-manage-docker-hub-organizations-and-teams/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bids
already has 9 users. Should we kick 8 people off to add 2?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, that was the "grandfathered" status that @rwblair was talking about.
Luckily, out of those 9 people, 3 regularly attend the maintainers meetings (Ross, Franklin, myself). Then there is (among 5 other people) a certain bidsappdev
user ... would be nice to get the credentials for that account, because then we could "repurpose" those to be shared among bids maintainers, wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think creating a shared account between trusted parties is the easiest way forward, and IIRC might avoid some issues etc whenever working with individual accounts. May be just bidsdev
or just bids
? (IIRC there is difference between organizations and users on docker hub; so may be should be ok)
Thank you @effigies !!! |
Checked the Winnower Google cache and found PDFs that we can use that seem more stable than the website. |
06cabfd
to
ddca51d
Compare
@sappelhoff @yarikoptic Having finally looked into what was involved in the docker container, it occurs to me that we can just use a standard container and install linkchecker in it. No need to push to any user's Docker repo. Let me know if there was a good reason I missed for using a custom image. |
everything ingenious is simple ;) I don't think there was a good reason really besides having a dedicated container/easier to test locally etc. |
that would be the best solution then :) |
Updated recipe, rebuilt, and pushed to my own repository for now. Let's see if this works.