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