For git-bare cooking to work, upgrade swh.storage to the latest version (> v0.35) and
restart the storage service (done).

Would you have time during September to help on this task? (it is a roadmap task, btw)

I discussed this option with Kat from Data Current (in charge of the SWH stories interface) and she was wondering if the highlighted text will be centered.
Seems from your example that this will be the case.

This is really good!
I discussed this option with Kat from Data Current (in charge of the SWH stories interface) and she was wondering if the highlighted text will be centered.
Seems from your example that this will be the case.

@anlambert we have discussed this task this morning with @ardumont and @vlorentz.
I want to start working on the improvements of the deposit admin view to open it up for deposit clients.
Would you have time during September to help on this task? (it is a roadmap task, btw)

Easiest option would be to add a link to the API endpoint.

In T3489#69769, @moranegg wrote:

@anlambert : Looks very good!
Can you show an example for a code fragment where you view a content with a few lines marked-up ?

@anlambert : Looks very good!
Can you show an example for a code fragment where you view a content with a few lines marked-up ?

The scheduler is getting there.
We are now able to trigger a runner for that part:

Cool! LGTM

@moranegg , @rdicosmo , after taking your comments into account, below should be the final design of the iframe view for content or directory:

The key examples are computer museum websites: they will want to keep the visitor on their website, for visibility reasons, and we need to cater to their needs.
Typically, we should be able to provide them with an embedded view that looks like this (possibly without the "download" and "save again" buttons)

In the future we will also need to answer a more complex use-case where the iframe resembles more as an embedded copy of the archive.

Do you have an example of a complex usecase to get a better idea of your needs ?

In the future we will also need to answer a more complex use-case where the iframe resembles more as an embedded copy of the archive.

@anlambert; after discussing with @rdicosmo, here are a few context elements:
We are working on different use cases for the iframe, the first is a rather simpler one with the SWH stories, where just having the source code in a minimalist way is best.
In the future we will also need to answer a more complex use-case where the iframe resembles more as an embedded copy of the archive.

where is the Permalinks tab? I do not see it in the images

Thanks for all this great work...
A few questions/remarks:

• where is the Permalinks tab? I do not see it in the images
• for the url, what about "/embed/" instead of "/iframe/"? "embed" seems to be the canonical term used to designate this kind of things (see YouTube, etc.)
• instead of "go to the archive", why not "View in the Software Heritage Archive"?
• it's great that the iframe can use the width and height attibutes! How do you plan to handle strange values (e.g.: width=10px height=200%)?

I would go for option 1 but the path breadcrumbs should remain as it enables to ease
the navigation inside the source code tree (especially when an iframe points to a directory).
I propose to put it below the iframe header, it will also be fixed.

That's really nice, but I still prefer the minimalist first iframe :-)

And I triggered re-cooking bundles that were requested in the last month.

Yeah SWHIDs are long so they eat a lot of horizontal space.

Looks better with the first implementation with "Go to the archive" :-)
With the badge, it seems right and left side aren't balanced.

The one thing that is missing is the current SWHID I’m viewing.
Maybe use a SWHID (or a badge) instead of the path in the center of the panel… or as a footer like a reference…
Not sure about this, but we need to know what artifact is identified in the iframe.

I agree, it looks great!

Note that the cache invalidation is not completely done though as the objstorage used
is an azure one.

Currently investigating how to clean that up.

Note that the cache invalidation is not completely done though as the objstorage used
is an azure one.

• status.io: Open maintenance ticket to notify of the partial disruption in service
• vangogh: Stop puppet
• vangogh: Stop gunicorn-swh-vault
• vault db: Schema migration [1]
• Upgrade workers and webapp nodes with latest swh.vault and restart cooker service
• Start back gunicorn-swh-vault
• Try a cooking and check result -> ok
• Close maintenance ticket as everything is fine

This looks great!

Some progress report on my work of the last days on the subject.

Fix has been deployed to production, issue is now fixed, closing this.

The cleanup of the old counters is done so it can be closed

Deployed on webapp nodes.

P1114 when ran sequentially does not seem to be exceeding 1 minute so the timing still happens every minute (in the diff).

I raised the priority for this as this seems to be a recurrent situation. Each time I
check this, it's right there, at least 3 refresh at the same time.

The computation of those metrics will be executed in production on a regular basis, probably each day, to keep them up to date.

Indeed, a quick htop which demonstrates it: