Archived repositories and the living infrastructure

[Michelle D'Souza]

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.justin at 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 <gtirloni at ocadu.ca <mailto:gtirloni at 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 at lists.idrc.ocad.ca <mailto:fluid-work at 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 at lists.idrc.ocad.ca
> To unsubscribe, change settings or access archives,
> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20200611/5eceb125/attachment.html>