Re: Per project repository snapcraft files?
I think there is a lot of misunderstanding here. In GitLab CI only test builds are done and artifacts are kept so people can test an AppImage or Flatpak without having to compile locally. Stable releases are done by the Release Team via scripts to tarballs. Flatpaks are done via Flathub and are done (usually) automatically via the Flatpak External Data Checker. Hopefully this clarifies the situation. On 21/8/23 08:48, Scarlett Moore wrote: On Sun, Aug 20, 2023, 4:14 PM Julius Künzel wrote: To me it seems this discussion is quite abstract and there are several misunderstandings because not everybody knows every detail of snap packaging and/or the KDE infrastructure (me neither). I understand that from an organizational perspective most people like the idea of having the files in the repos, but have technical doubts. Hence, I wonder whether it would be a good idea to take one KDE app to try and showcase this suggestion? Cheers, Julius Sounds like a great idea to me. Scarlett 20.08.2023 17:55:24 Laura David Hurka : > On Sunday, August 20, 2023 12:47:10 PM CEST Ben Cooksley wrote: >> On Sun, Aug 20, 2023 at 12:43 PM Scarlett Moore < >> >> scarlett.gately.mo...@gmail.com> wrote: >>> Only on release! We will not be building from master! We don't want >>> unstable snaps. >>> Thanks, >>> Scarlett >> >> In that particular case the jobs should be manually triggered only. >> >> Gitlab CI is really made for building artifacts for a given commit rather >> than for a specified version though, so this is definitely going to be a >> case of things not fitting quite right. >> >> Cheers, >> Ben >> [...] > > This confuses me too. > It seems Scarlett wants to use a “deploy” stage [1] and a job rule [2] > to run snap build jobs automatically when the release is done. > > If you mean that Gitlab CI should not be used to automate release jobs, > you should elaborate more how binary-factory is meant to be replaced. > > Otherwise, do you just note that Gitlab CI is suboptimal, > or do you recommend to use something else? > Like: “Release build: automatic is fine. Release publish: please only manual”? > > Cheers, David > > > [1] https://docs.gitlab.com/ee/ci/yaml/#stages > [2] like this: > snap-release-job: > rules: > -if: $CI_COMMIT_TAG =~ /^v[0-9][0-9]\.[0-9][0-9]\.[0-9][0-9]$/ > [...] > see also: https://docs.gitlab.com/ee/ci/jobs/job_control.html#use-predefined-cicd-variables-to-run-jobs-only-in-specific-pipeline-types
Re: Per project repository snapcraft files?
On Sun, Aug 20, 2023, 4:14 PM Julius Künzel wrote: > To me it seems this discussion is quite abstract and there are several > misunderstandings because not everybody knows every detail of snap > packaging and/or the KDE infrastructure (me neither). > > I understand that from an organizational perspective most people like the > idea of having the files in the repos, but have technical doubts. Hence, I > wonder whether it would be a good idea to take one KDE app to try and > showcase this suggestion? > > Cheers, > Julius > > Sounds like a great idea to me. Scarlett > > > > 20.08.2023 17:55:24 Laura David Hurka : > > > On Sunday, August 20, 2023 12:47:10 PM CEST Ben Cooksley wrote: > >> On Sun, Aug 20, 2023 at 12:43 PM Scarlett Moore < > >> > >> scarlett.gately.mo...@gmail.com> wrote: > >>> Only on release! We will not be building from master! We don't want > >>> unstable snaps. > >>> Thanks, > >>> Scarlett > >> > >> In that particular case the jobs should be manually triggered only. > >> > >> Gitlab CI is really made for building artifacts for a given commit > rather > >> than for a specified version though, so this is definitely going to be a > >> case of things not fitting quite right. > >> > >> Cheers, > >> Ben > >> [...] > > > > This confuses me too. > > It seems Scarlett wants to use a “deploy” stage [1] and a job rule [2] > > to run snap build jobs automatically when the release is done. > > > > If you mean that Gitlab CI should not be used to automate release jobs, > > you should elaborate more how binary-factory is meant to be replaced. > > > > Otherwise, do you just note that Gitlab CI is suboptimal, > > or do you recommend to use something else? > > Like: “Release build: automatic is fine. Release publish: please only > manual”? > > > > Cheers, David > > > > > > [1] https://docs.gitlab.com/ee/ci/yaml/#stages > > [2] like this: > > snap-release-job: > > rules: > > -if: $CI_COMMIT_TAG =~ /^v[0-9][0-9]\.[0-9][0-9]\.[0-9][0-9]$/ > > [...] > > see also: > https://docs.gitlab.com/ee/ci/jobs/job_control.html#use-predefined-cicd-variables-to-run-jobs-only-in-specific-pipeline-types >
Re: Per project repository snapcraft files?
To me it seems this discussion is quite abstract and there are several misunderstandings because not everybody knows every detail of snap packaging and/or the KDE infrastructure (me neither). I understand that from an organizational perspective most people like the idea of having the files in the repos, but have technical doubts. Hence, I wonder whether it would be a good idea to take one KDE app to try and showcase this suggestion? Cheers, Julius 20.08.2023 17:55:24 Laura David Hurka : > On Sunday, August 20, 2023 12:47:10 PM CEST Ben Cooksley wrote: >> On Sun, Aug 20, 2023 at 12:43 PM Scarlett Moore < >> >> scarlett.gately.mo...@gmail.com> wrote: >>> Only on release! We will not be building from master! We don't want >>> unstable snaps. >>> Thanks, >>> Scarlett >> >> In that particular case the jobs should be manually triggered only. >> >> Gitlab CI is really made for building artifacts for a given commit rather >> than for a specified version though, so this is definitely going to be a >> case of things not fitting quite right. >> >> Cheers, >> Ben >> [...] > > This confuses me too. > It seems Scarlett wants to use a “deploy” stage [1] and a job rule [2] > to run snap build jobs automatically when the release is done. > > If you mean that Gitlab CI should not be used to automate release jobs, > you should elaborate more how binary-factory is meant to be replaced. > > Otherwise, do you just note that Gitlab CI is suboptimal, > or do you recommend to use something else? > Like: “Release build: automatic is fine. Release publish: please only manual”? > > Cheers, David > > > [1] https://docs.gitlab.com/ee/ci/yaml/#stages > [2] like this: > snap-release-job: > rules: > -if: $CI_COMMIT_TAG =~ /^v[0-9][0-9]\.[0-9][0-9]\.[0-9][0-9]$/ > [...] > see also: > https://docs.gitlab.com/ee/ci/jobs/job_control.html#use-predefined-cicd-variables-to-run-jobs-only-in-specific-pipeline-types
Re: Per project repository snapcraft files?
On Sunday, August 20, 2023 12:47:10 PM CEST Ben Cooksley wrote: > On Sun, Aug 20, 2023 at 12:43 PM Scarlett Moore < > > scarlett.gately.mo...@gmail.com> wrote: > > Only on release! We will not be building from master! We don't want > > unstable snaps. > > Thanks, > > Scarlett > > In that particular case the jobs should be manually triggered only. > > Gitlab CI is really made for building artifacts for a given commit rather > than for a specified version though, so this is definitely going to be a > case of things not fitting quite right. > > Cheers, > Ben > [...] This confuses me too. It seems Scarlett wants to use a “deploy” stage [1] and a job rule [2] to run snap build jobs automatically when the release is done. If you mean that Gitlab CI should not be used to automate release jobs, you should elaborate more how binary-factory is meant to be replaced. Otherwise, do you just note that Gitlab CI is suboptimal, or do you recommend to use something else? Like: “Release build: automatic is fine. Release publish: please only manual”? Cheers, David [1] https://docs.gitlab.com/ee/ci/yaml/#stages [2] like this: snap-release-job: rules: -if: $CI_COMMIT_TAG =~ /^v[0-9][0-9]\.[0-9][0-9]\.[0-9][0-9]$/ [...] see also: https://docs.gitlab.com/ee/ci/jobs/job_control.html#use-predefined-cicd-variables-to-run-jobs-only-in-specific-pipeline-types
New project to translate videos subtitles
Hi, Inspired by the accessibility goal, Promo had the idea of including subtitles and closed captions for videos for several KDE projects (Akademy interviews, GCompris videos like https://tube.kockatoo.org/w/symxHCzUj9TA7LZoZagD9c...). I've created a repository which handles the conversion from subtitles <=> po files for translators using KDE scripts (https://invent.kde.org/jjazeix/srt2po) and Translate Toolkit. There is also a script to upload the subtitles to the KDE peertube instance. There could be several issues with translating only the text but I still think it's worth it to be able to translate them using the usual KDE workflow: * if we want to display some lines longer because the translated text takes more time to read; * if we want to add extra texts at different times. In order to workaround these issues, the project will also allow translator to directly write the srt files instead of passing by a po file. All the srt files will be centralised here, which will avoid translators to look for them. In which gitlab group would it be better to create this repository and what would be the process to create it? Accessibility ou Utilities seem good to me but as it will contain more data than scripts/code, maybe there is a better place for it. Cheers, Johnny
Re: Per project repository snapcraft files?
On Sun, Aug 20, 2023 at 12:43 PM Scarlett Moore < scarlett.gately.mo...@gmail.com> wrote: > Only on release! We will not be building from master! We don't want > unstable snaps. > Thanks, > Scarlett > In that particular case the jobs should be manually triggered only. Gitlab CI is really made for building artifacts for a given commit rather than for a specified version though, so this is definitely going to be a case of things not fitting quite right. Cheers, Ben > > On Sat, Aug 19, 2023, 4:03 PM Nate Graham wrote: > >> On 8/19/23 15:45, Scarlett Moore wrote: >> > No. It will be telling launchpad to build them via API. Launchpad will >> > upload to store its own artifacts. Our current setup has launchpad >> > sending the snaps back to our server and we upload to store. This new >> > proposal would be significantly less data going back and forth. Also, >> do >> > the stable branches really have many commits? I thought once branched >> to >> > stable release branch it was done... I reiterate that launchpad is >> doing >> > all the heavy lifting including store uploads. Do users download >> > flatpaks from kde servers? The button says flathub. How do they get >> there? >> > Scarlet >> If Launchpad needs to build our Snaps as a part of the release process, >> that's something that will need to happen only a few times a year. Apps >> on FlatHub are similarly built for us by FlatHib infrastructure. It's >> fine. >> >> But asking Launchpad to build us a Snap for every commit is another >> matter. KDE apps get at least one commit per day just due to >> translations, and popular apps may get many commits per day and many >> merge requests. I can think of a large variety of issues that could be >> caused by asking Launchpad to build Snaps at this much higher frequency >> level. >> >> So can we clarify the proposal? Are you asking to have Launchpad build >> Snaps as a part of the CI process, for every commit and merge request? >> Or just as a part of the release process that happens a few times a year? >> >> Nate >> >
