Testing JavaScript Inside SVG

To verify the browser behavior, I created a small test repository containing an SVG clock. The file includes a JavaScript timer that updates the displayed date and time every second, making it immediately clear whether the script has been executed.

I tested the same SVG in several embedding contexts:

The important distinction is not whether SVG supports JavaScript, because it does. The restriction depends on how the browser loads the file.

When SVG is used as an image, browsers apply a restricted processing mode for security and privacy reasons. In this context, scripts and external resources are disabled. This behavior is documented by MDN’s guide to SVG as an image and by the SVG 2 conformance rules, which describe the secure image processing modes.

Gitea’s Rendering Makes the Difference

The CommonMark image specification defines Markdown images as HTML img elements. My first test used an SVG stored in the same repository, and Gitea kept it as img, so the script did not run.

Daniel later observed a different case on src.opensuse.org: an HTTPS SVG badge served from the openSUSE infrastructure was embedded as an object and did update after its 30-second timer. That distinction matters because scripts are disabled in img, but can run when the SVG is loaded as an object.

The live obs-git-explorer badge confirms the second case. It is served as image/svg+xml, contains a setInterval that runs every 30 seconds, fetches fresh results from the same gitexplorer.opensuse.org origin, and updates its text and colors.

This also limits theme integration. An SVG image may use prefers-color-scheme to follow the browser or operating-system preference, but an externally loaded SVG still cannot directly reuse Gitea’s page CSS.

Implications for obs-status-service

This means live updates may be possible for obs-status-service, but only if Gitea embeds the generated badge as object.

The practical approach would be simple:

• Serve the visible badge as SVG.
• Let the SVG JavaScript fetch the equivalent .json URL.
• Update the badge text and colors from that JSON response.

If Gitea keeps the badge as img, the SVG remains static and server-side rendering is still the fallback. The key conclusion is that Markdown syntax is not enough to decide this; the final DOM matters: img is static, while object can support a self-updating SVG.

obs-status-service exposes Open Build Service (OBS) build results as SVG, JSON, or XML so they can be integrated into the openSUSE Git workflow. Before working on the issues, I studied the service, the surrounding repository, and the connection between Gitea, Redis, and OBS.

Local Test Mode

My first contribution addressed autogits issue #113, which requested a way to run obs-status-service locally without requiring a real Redis server.

The implementation included:

• Creating a mock Redis client for local development.
• Providing a test mode that runs without an external Redis instance.
• Loading realistic OBS test data from a compressed JSON file.

I submitted these changes in pull request #118. This reduces the infrastructure required to start contributing. Developers can run the service locally, inspect realistic project and package results, and test changes without first configuring access to an OBS Redis server.

Default Service Page

My second contribution worked on autogits issue #114. Previously, visiting the root URL of obs-status-service only returned a 404 response. The goal was to provide a useful landing page for the service.

I created a small interface where users can enter an OBS project, package, repository, and architecture. The page builds the corresponding status URL, shows an SVG preview, and generates a Markdown snippet that can be copied into a README. This makes the available endpoints easier to discover and avoids requiring users to construct their URLs manually. I also separated the static assets and used Pico CSS for lightweight styling.

This work was submitted in pull request #119.

Preparing the Project

Both contributions improve the entry points to the project: one makes the development environment more accessible, while the other makes the service more understandable for its users. They also established a useful foundation for the main GSoC work on improving how OBS build results are generated, displayed, and integrated into the Git workflow.

The Project: Enhancing openSUSE Git Workflow

During the next 12 weeks, I will be working on improving the obs-status-service. Under the mentorship of Daniel García Moreno (dgarcia) and Doug, my main objectives include:

• Improving Visualizations: Extending the Go tool to generate better SVG images with new CSS styles and making them interactive with JavaScript.
• Gitea Bot Integration: Implementing a new bot for Gitea that provides useful build information directly inside Pull Requests.
• AI Integration (Stretch Goal): Exploring the use of AI through Log Detective to analyze and assist with PRs that fail to build.

Moving Forward

Given the dynamic nature of the GSoC program and software development itself, it’s very likely that these initial goals will adapt and change slightly as the weeks go by.

I’m ready to learn, face new challenges, and contribute to the open-source community. Stay tuned, as I will be posting my weekly progress right here!