Archived repositories and the living infrastructure

Justin Obara obara.justin at gmail.com
Tue Jun 16 14:09:20 UTC 2020


Hi everyone,

Slight update. We decided to pull in the prefsEditors from the GPII org. It is now located at https://github.com/fluid-project/prefs-editors-prototypes <https://github.com/fluid-project/prefs-editors-prototypes> and has bee unarchived for the purpose of supporting deployment.

Thanks
Justin

> On Jun 16, 2020, at 9:28 AM, Justin Obara <obara.justin at gmail.com> wrote:
> 
> Hi Gio,
> 
> Thanks for the info.
> 
> I’ve unarchived https://github.com/fluid-project/videoPlayer <https://github.com/fluid-project/videoPlayer>; however, https://github.com/GPII/prefsEditors <https://github.com/GPII/prefsEditors> is not part of our GitHub organization. Instead I’ve forked it to https://github.com/fluid-project/prefsEditors <https://github.com/fluid-project/prefsEditors> and you can deploy from there instead. In the future we may want to drop our fork and just maintain the deployments from the GPII GitHub org.
> 
> Thanks
> Justin
> 
>> On Jun 11, 2020, at 9:42 AM, Giovanni Tirloni <gtirloni at ocadu.ca <mailto:gtirloni at ocadu.ca>> wrote:
>> 
>> Hi Justin,
>> 
>> Today, the build site is built by 8 different CI/CD jobs <https://github.com/fluid-project/ci-service/tree/master/jenkins_jobs> that pull data from various repositories and builds them (or not) in different ways. That information is not linked in any way to the repositories since the build instructions live in the ci-service repository.
>> 
>> I'm trying to make each repository self-sufficient so it knows how to build and serve itself in a minimal/standardized way. The first step is to add the Dockerfile that codifies the build instructions. The next step is to hook this into GitHub Actions so it's built and deployed automatically.
>> 
>> From there, developers are free to modify and deploy new versions, as necessary. Change the build instructions, if needed. They don't need to learn about a new repository with different conventions, maybe custom scripts, gotchas, etc.
>> 
>> For repositories that are archived and don't need to be built ever again (just served forever), the build site creates some challenges to implement that approach. We can either fully enabled CI/CD for them or not enable it at all (thus my suggestion to copy the built static content into the build.fluidproject.org <http://build.fluidproject.org/>repository -- maybe in an archived directory of sorts).
>> 
>> Thanks,
>> Gio
>> 
>> From: Justin Obara <obara.justin at gmail.com <mailto:obara.justin at gmail.com>>
>> Sent: Thursday, June 11, 2020 08:58
>> To: Giovanni Tirloni <gtirloni at ocadu.ca <mailto:gtirloni at ocadu.ca>>
>> Cc: fluid-work at lists.idrc.ocad.ca <mailto:fluid-work at lists.idrc.ocad.ca> <fluid-work at lists.idrc.ocad.ca <mailto:fluid-work at lists.idrc.ocad.ca>>
>> Subject: Re: Archived repositories and the living infrastructure
>>  
>> 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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20200616/8855a87c/attachment.htm>


More information about the fluid-work mailing list