SoK/2023/StatusReport/Neelaksh Singh: Difference between revisions

From KDE Community Wiki
No edit summary
 
Line 7: Line 7:


'''Introduction and Abstract:'''
'''Introduction and Abstract:'''
Currently only one computer program in the Global Ecolabelling Network is certified with the Blue Angel ecolabel: [https://eco.kde.org/blog/2022-03-16-press-release-okular-blue-angel/ KDE's Okular]. As part of the new [https://community.kde.org/Goals/Sustainable_Software sustainability goal], we would like to add more KDE apps, in particular GCompris and Kate, to the list.
Flatpak is a new method of packaging and distributing applications that let KDE developers offer them easily for a lot of users via Flathub. Automating build and packaging checks in CI is one of KDE's goals for the next two years ([https://community.kde.org/Goals/Automate_and_systematize_internal_processes Automate and systematize internal processes]).
Building on the work from previous SoK project, my task was to setup Flatpak builds in KDE's GitLab CI (as shown in [https://invent.kde.org/users/neelusingh/contributed invent.kde.org]) for KDE Applications. As the next step, I turned these applications to Nightly builds in the [https://invent.kde.org/packaging/flatpak-kde-applications Flatpak Repository].


To obtain the Blue Angel ecolabel, applications must demonstrate compliance with a list of criteria, including energy consumption transparency and user autonomy. KDE has an advantage here, since being Free Software we are already fulfilling many aspects of the criteria. The candidate will be responsible for completing what is needed to submit at least two applications for Blue Angel eco-certification, including (a) updating online documentation for the [https://mail.kde.org/pipermail/energy-efficiency/2021-September/000025.html user autonomy criteria] for GCompris and Kate, and (b) testing usage scenario scripts before the software can be measured in the [https://eco.kde.org/blog/2022-07-25-sprint-lab-follow-up/ community lab].
There already exists manifests for KDE applications hosted on Flathub. My work aimed to move manifest files for as many of these KDE applications to their respective repository on GitLab, to give benefits from checks during Merge Requests via KDE Invent's GitLab CI.


'''Mentor:'''
'''Mentor:'''
Timothée Ravier (@siosm:matrix.org)
Timothée Ravier (@siosm:matrix.org) & Aleix Pol (@apol:kde.org)
Aleix Pol (@apol:kde.org)


'''Blog Posts: '''
'''Blog Posts: '''
Line 19: Line 20:
[https://rinkiakepapa.hashnode.dev/cicd-with-flatpak CI/CD with Flatpak]
[https://rinkiakepapa.hashnode.dev/cicd-with-flatpak CI/CD with Flatpak]


'''Files and Links'''
'''Files and Links:'''


[https://hackmd.io/@travier/rJojD9xMi HackMD]
[https://hackmd.io/@travier/rJojD9xMi HackMD]
Line 31: Line 32:


'''WEEKS 4 - 9:'''
'''WEEKS 4 - 9:'''
I stated to raise PR's for application with their respective flatpak manifest, along with license file. Also added the flatpak build pipeline to `.gitlab.ci`
I stated to raise PR's for application with their respective flatpak manifest, along with license file. Also added the flatpak build pipeline to .gitlab.ci . I opened PR's for almost 50+ applications that are currently being hosted on Flathub.
The general process I followed was forking the application, using the Web IDE provided by GitLab I would add all the necessary files and lines.
For adding manifests, I took the manifest on Flathub to be the source of truth and added the same to the respective applications after making the required changes.
At starting we were using the KDE platform runtime version as 5.15-21.08 which was later changed to the new an updated 5.15-22.08 version.


'''WEEKS 10 - 12:'''
'''WEEKS 10 - 12:'''
Most of the days were spent in cleaning up the files and getting regular updates on the merge status. I focused on writing blog as well as including the nightly builds for the application that were successfully building the  
Most of the days were spent in resolving application mentor's queries on the PR's and getting regular updates on the merge status. I focused on writing blog as well as including the nightly builds for the application that were successfully building the flatpak build artifacts.


===== Overall Experience =====
The entire program was quite intuitive as I got to learn about a completely new tooling test suit. A large part of the program success goes to my mentors who provided their advice and guidance whenever/wherever needed. This was made possible through our regular weekly sync-ups. 


'''CONTACT ME:'''
'''CONTACT ME:'''
Matrix: @neelaksh:matrix.org
Matrix: @neelaksh:matrix.org

Latest revision as of 11:40, 13 April 2023

Systematization 1: Automate Flatpak checks in GitLab Invent CI

Adding Flatpak CI/CD to Application Repository

Project type: CI/CD pipeline | Script | Documentation

Introduction and Abstract: Flatpak is a new method of packaging and distributing applications that let KDE developers offer them easily for a lot of users via Flathub. Automating build and packaging checks in CI is one of KDE's goals for the next two years (Automate and systematize internal processes).

Building on the work from previous SoK project, my task was to setup Flatpak builds in KDE's GitLab CI (as shown in invent.kde.org) for KDE Applications. As the next step, I turned these applications to Nightly builds in the Flatpak Repository.

There already exists manifests for KDE applications hosted on Flathub. My work aimed to move manifest files for as many of these KDE applications to their respective repository on GitLab, to give benefits from checks during Merge Requests via KDE Invent's GitLab CI.

Mentor: Timothée Ravier (@siosm:matrix.org) & Aleix Pol (@apol:kde.org)

Blog Posts:

CI/CD with Flatpak

Files and Links:

HackMD

Apps with successful flatpak pipeline and Nightly Builds

Weekly Progress

WEEKS 1 - 3: I started by getting acquainted with the KDE community and learning about Flatpak Packaging. I also familiarized myself with the Flathub ecosystem and understanding the key aspects missing in the manifests present in the flatpak repository. We discussed PoA for getting the correct manifest files, standardized approach for adding them to respective applications and adding the necessary license file. We decided upon the distribution of work in phases and created the hackmd file for tracking changes and updates.

WEEKS 4 - 9: I stated to raise PR's for application with their respective flatpak manifest, along with license file. Also added the flatpak build pipeline to .gitlab.ci . I opened PR's for almost 50+ applications that are currently being hosted on Flathub. The general process I followed was forking the application, using the Web IDE provided by GitLab I would add all the necessary files and lines. For adding manifests, I took the manifest on Flathub to be the source of truth and added the same to the respective applications after making the required changes. At starting we were using the KDE platform runtime version as 5.15-21.08 which was later changed to the new an updated 5.15-22.08 version.

WEEKS 10 - 12: Most of the days were spent in resolving application mentor's queries on the PR's and getting regular updates on the merge status. I focused on writing blog as well as including the nightly builds for the application that were successfully building the flatpak build artifacts.

Overall Experience

The entire program was quite intuitive as I got to learn about a completely new tooling test suit. A large part of the program success goes to my mentors who provided their advice and guidance whenever/wherever needed. This was made possible through our regular weekly sync-ups.

CONTACT ME: Matrix: @neelaksh:matrix.org