I wonder if it’s also time for us to consider how/if we use build.fluidproject.org <http://build.fluidproject.org/>. I’m pretty sure links to it have been in reports and sent to funders, but I don’t think we’ve updated the site in quite a while. Thoughts? Does anyone use it? Should we use? For what?
Thanks, Michelle > On Jun 11, 2020, at 7:58 AM, Justin Obara <obara.jus...@gmail.com> wrote: > > Hi Gio, > > I don’t know the full details of what’s needed, but it sounds like the first > option would be the easiest approach. However, we’d need to update the > description to indicate that it is still not in active development and that > it’s just to support the deployment needs. > > Regarding your second option, would it be possible to have another repo, > which I guess could be the build site, that, as part of it’s CI/CD process, > did a checkout of the archived repos that need to be deployed? In that way we > can still track the code for the archived repos in their own locations. > > Thanks > Justin > >> On Jun 10, 2020, at 8:22 PM, Giovanni Tirloni <gtirl...@ocadu.ca >> <mailto:gtirl...@ocadu.ca>> wrote: >> >> Hello, >> >> Our infrastructure is evolving and one of the main goals is to run all our >> applications on containers. For that, the apps/websites need to be >> "containerized", that is, they must have a Dockerfile and a published image. >> >> While working on containerizing some of our apps, I encountered a few >> repositories that are archived (read-only): >> >> https://github.com/fluid-project/videoPlayer >> <https://github.com/fluid-project/videoPlayer> >> https://github.com/GPII/prefsEditors <https://github.com/GPII/prefsEditors> >> >> Although they are archived, they are still served publicly at >> https://build.fluidproject.org <https://build.fluidproject.org/> as separate >> modules/paths. >> >> That creates a dilemma for me because I need to properly integrate them into >> a CI/CD workflow. They will likely require more changes as new Docker images >> are released and they need to be updated for security fixes, etc. In other >> words, no more work is planned on these projects but they are still very >> much alive in the infrastructure. >> >> I see two paths forward: >> They are unarchived so I can submit PRs to have the Dockerfile added (and >> future changes). >> They are copied into the build.fluidproject.org >> <http://build.fluidproject.org/> and served as static content from there >> Any thoughts? >> >> Regards, >> Giovanni Tirloni >> DevOps Engineer >> Inclusive Design Research Centre, OCAD University >> https://idrc.ocadu.ca >> <https://idrc.ocadu.ca/>_______________________________________________________ >> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca >> <mailto:fluid-work@lists.idrc.ocad.ca> >> To unsubscribe, change settings or access archives, >> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work >> <https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work> > _______________________________________________________ > fluid-work mailing list - fluid-work@lists.idrc.ocad.ca > To unsubscribe, change settings or access archives, > see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
_______________________________________________________ fluid-work mailing list - fluid-work@lists.idrc.ocad.ca To unsubscribe, change settings or access archives, see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
