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.jus...@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 <gtirl...@ocadu.ca >> <mailto:gtirl...@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.jus...@gmail.com <mailto:obara.jus...@gmail.com>> >> Sent: Thursday, June 11, 2020 08:58 >> To: Giovanni Tirloni <gtirl...@ocadu.ca <mailto:gtirl...@ocadu.ca>> >> Cc: fluid-work@lists.idrc.ocad.ca <mailto:fluid-work@lists.idrc.ocad.ca> >> <fluid-work@lists.idrc.ocad.ca <mailto:fluid-work@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 <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
