Merge pull request #253 from rajuljha/chore/report/week6

chore(report) : Add week 6 report CI Scanner Project

docs/2024/ci-scanner/updates/2024-07-11.md

@@ -0,0 +1,66 @@
+---
+title: Week 6
+author: Rajul Jha
+tags: [gsoc24, CI]
+---
+<!--
+SPDX-License-Identifier: CC-BY-SA-4.0
+
+SPDX-FileCopyrightText: 2024 Rajul Jha <rajuljha49gmail.com>
+-->
+
+# Week 6
+*(July 05, 2024 - July 11, 2024)*
+
+## Meeting 1
+*(July 10, 2024)*
+
+## Attendees
+* [Rajul Jha](https://github.com/rajuljha)
+* [Shaheem Azmal](https://github.com/shaheemazmalmmd)
+* [Kaushlendra](https://github.com/Kaushl2208)
+* [Avinal Kumar](https://github.com/avinal)
+
+## Discussions
+* Mentioned about the progress and completion of [#PR2785](https://github.com/fossology/fossology/pull/2785) which adds the relevant byte info the nomos scanner's JSON Output.
+* Also got review from mentors regarding [#PR2784](https://github.com/fossology/fossology/pull/2784) which allows for the user to pass a custom `allowlist.json` file for whitelisting certain licenses or keywords.
+* Gave a demo to the mentors on how the Github Action for Fossology Scanners works. I studied `docker` actions as well as `composite` actions and decided to go for the composite actions because:
+  * **Emulation on our end**: Composite actions give us the flexibility to run multiple steps in our jobs which makes it easier for us to implement QEMU Emulator for cross platform image support de-facto.
+  * **Uploading Artifacts**: Using composite actions, the user does not need to set up a separate step of uploading the results as an artifact, as we can add this step into our action itself. User can just provide the `report_format` key to tell the script which report to generate. Thus, it ensures less clout for the user.
+
+
+## Work Done
+* Completed the allowlist functionality and sent a [#PR2784](https://github.com/fossology/fossology/pull/2784) for the same.
+  * The user can now pass a `allowlist.json` file in a particular [format](https://github.com/fossology/fossology/blob/master/utils/automation/allowlist.sample.json) like this:
+    ```yaml
+    {
+    "licenses": [
+            "GPL-2.0-or-later",
+            "GPL-2.0-only",
+            "LGPL-2.1-or-later"
+        ],
+        "exclude": [
+            "*/agent_tests/*",
+            "src/vendor/*"
+        ]
+    }
+    ```
+  * The script looks for the file allowlist file first. If not found here, then looks for `allowlist.json` file in the root directory. If not found here then looks for `whitelist.json`. If this is also not found, populates an empty dictionary with `license` and `exclude` keys.
+  The decision tree looks like this:
+
+    ![Screenshot](/img/ci/Whitelist_decision_tree.png)
+
+* As discussed and resolved in the previous meeting, the `start`, `end`, and `len` information is updated into the nomos JSON output in this [#PR2785](https://github.com/fossology/fossology/pull/2785).
+
+    ![Screenshot](/img/ci/Nomos_json_output.png)
+
+* Started working on the line number part for `nomos` and `ojo` scanners.
+
+* Researched and understood the different Github Actions and decided to go with [`composite` actions](https://docs.github.com/en/actions/creating-actions/creating-a-composite-action) as they allow us to customize our action in an easier manner.
+* Implemented a demo Github Action for testing and demo'd it to the mentors.
+![Screenshot](/img/ci/foss-action-test.png)
+
+## Planning for next week
+* Need to complete the action, test all cases and boundary conditions.
+* Once the action is completed, we need to think about a name for it and publish it to the Github Marketplace.
+* After that, resume working on the line number part for the `nomos` and `ojo` scanners as well.