Great news :-)

• version 0.1.296(swh2) released and deployed on all the webapp

Current deployment tryout of D5520 is currently running on staging and i'm happy to
report it's working as expected.

chardin.js library is also interesting, it creates a simple overlay to display instructions on existent elements instead of using popups.

Bootstrap Tour also looks great, simple to use, easy configuration, also a good candidate.

The intro.js library seems pretty simple to use, can be configured through JSON, can provide guided tour but also UI hints and is highly customizable.

I tried this:

swh-web v0.0.295 is released and deployed on staging and production.

The puppet script generating the aggragated data is updated and was run to refresh the data.
The webapp can be released with this diff now

one additional point before releasing this, the puppet script making the aggregation need to be improved as it only merge the data for the content graph :
https://forge.softwareheritage.org/source/puppet-swh-site/browse/production/site-modules/profile/files/stats_exporter/export_archive_counters.py$109

In T3247#63114, @rdicosmo wrote:

Ok, this is converging with the discussion in T3234: we fully agree that having proper errors reported to the user is the way to go, so let's forget about the "sanitization" approach.

Better error message regarding what part of a SWHID did not get validated should be returned by the API though.

This would be a definite plus in all cases: how difficult would it be to report proper errors?

If we report a precise error that helps the user fix the issue, instead of the current "Internal format error", then I'm with you :-)

Ok, this is converging with the discussion in T3234: we fully agree that having proper errors reported to the user is the way to go, so let's forget about the "sanitization" approach.

In T3234#63111, @anlambert wrote:

hence, a fix is needed in the code underlying the URL generation for the Permalinks tab (this is for @anlambert :-))

@vlorentz , @anlambert : thanks for progressing the discussion on this issue.
After mulling over your inputs, here is my current understanding:

In T3247#63105, @rdicosmo wrote:

I wonder if this is not overkill: SWHID may evolve in the future, and maintaining two implementations (one of them in JS!) may be source of headaches down the line.
A simple "sanitization" phase in the frontend catching the most common issues (trailing slashes, leading or trailing tabs or spaces, etc.) would probably be enough for our purpose.

I wonder if this is not overkill: SWHID may evolve in the future, and maintaining two implementations (one of them in JS!) may be source of headaches down the line.
A simple "sanitization" phase in the frontend catching the most common issues (trailing slashes, leading or trailing tabs or spaces, etc.) would probably be enough for our purpose.

The P1005 convert the data added by the webapp to json data that can be added to the /usr/local/share/swh-data/history-counters.munin.json file.
This content can be added on the file before the change on the webapp is released. it will just add few duplicate points to render, but with no effect on the final rendering

It could but not immediately.
Let's see if i can actually pull it off ;)

Thanks for this!

In T3087#63054, @vsellier wrote:

Are we planning to add a way to notify the mirrors of the takedown notices ?

Are we planning to add a way to notify the mirrors of the takedown notices ?
I'm just thinking if it could be interesting to subscribe the staging environment to it to ensure the content is also removed from it (and also flagged to avoid any further ingestion).

• swh-site: Deploy one systemd unit (per worker) which is able to deal with all the existing save code now requests and subscribed to the one high priority queue. Loaders are: loader-git, loader-svn, loader-mercurial for now.

There is only one origin URL in the archive ending with double slashes:

softwareheritage=> select * from origin where url ilike '%//' limit 10;
    id    |                          url                           
----------+--------------------------------------------------------
 89946580 | https://github.com/wookey-project/app-wookey-crypto///

In T3234#62986, @anlambert wrote:

• origin and path cannot be ended with double slashes, transform into single slash in that case

I guess the simplest fix will be to automatically remove the trailing slash of such malformed SWHID frontend side after a user copied pasted it in the search box.

As a compromise, we could accept this trailing slash, but show a warning on the interface and/or codify in the SWHID specification an exhaustive list of "fixes" that user interfaces can/should do.

There are already many URLs in the open

There are already many URLs in the open, so even if we remove the trailing slash now, that does not solve the problem.

What about removing the trailing / from generated URLs like this one instead?

great news!

I finally found why the graphs looks weird : https://forge.softwareheritage.org/source/swh-web/browse/master/swh/web/misc/urls.py$31
With a dirty patch on the server, it's way better:

\o/

The pipeline is deployed in staging.
It's working but it seems the graphs need some initial values in staging to make the rendering correctly:

It has been deployed to production, closing this.

This is now deployed to production.

Operationally, there's two axes we can play with:

Hey, can I take this task up next?

Great!

Thanks @faux, it will be deployed with next swh-web release.

@ardumont we briefly discussed this a while ago with @olasd. I think the proposed
solution was indeed to have a separate queue (and workers) for "save code now"
request, but not necessarily one separate queue per loader,

@ardumont we briefly discussed this a while ago with @olasd. I think the proposed solution was indeed to have a separate queue (and workers) for "save code now" request, but not necessarily one separate queue per loader, because the current priority system wasn't considered to be "fast enough". Maybe we can discuss this briefly with him and synthesize here what you come up with?

We already have a priority queue system in place in the scheduler. And for example, the
archive schedules save code now requests with a priority high [1]

Ok cool.

so for a user having an id like this in the tooltip would feel like an arbitrary string