We should investigate why they are there.

This is now done, aside from a minor issue noted below:

softwareheritage-indexer=# select count(*) from revision_intrinsic_metadata where metadata = '{"@context": "https://doi.org/10.5063/schema/codemeta-2.0"}'::jsonb;
 count 
-------
     0
(1 row)

Build is green
See https://jenkins.softwareheritage.org/job/DWAPPS/job/tox/403/ for more details.

Rebase

Build is green
See https://jenkins.softwareheritage.org/job/DCIDX/job/tox/525/ for more details.

Build has FAILED

• rebase

I don't think it's a good idea to move specs from the specific components they specify to a different repository (swh-docs), because that will just increase the chances (which are already quite high) that they will get out of sync.

In T1683#31104, @zack wrote:

That was my point about "swh-docs as a fallback".

In D1430#31493, @anlambert wrote:

I knew about the manual landing from us but I am not a big fan of all this noise added to the commit message by arc.
Based on my understanding, if the original commit author is able to push after we accept a diff, this noise will not
be present. Anyway, that's not a blocker to integrate changes so I will also proceed like this in the future.

That's only because I've (erroneously, this time) used arc land instead of arc land --squash.

In D1430#31490, @anlambert wrote:

Third: everyone else: once a change is accepted, you can land it yourself by doing first arc diff D1430 and then arc land

I think you mean arc patch D1430 then arc land

Third: everyone else: once a change is accepted, you can land it yourself by doing first arc diff D1430 and then arc land

@mcv21: first, apologies for the conflicting communication. We don't have a lot of external contributors (yet), so our processes are not very oiled on that front (yet).

In T1683#31093, @moranegg wrote:

The problem with having it in the docs, is that specs of higher level (like metadata workflow) must be in a specific repository, or can I have a specs folder in swh-environment?

@vlorentz, looking at the commits history of the documentation repository, only team members have pushed on it (which are de facto members of the Developers project)

@anlambert non-developers have been able to push accepted diffs to master in the past

Ok, so the fact that you are not able to push is that you are not a member of the Developers phabricator project.
As you can see on the repository policies, there is a push restriction on that specific users group.

@vlorentz thus:

mv3@deskpro108655:/upstreams/SoftwareHeritage/swh-docs$ git remote -v
origin  ssh://git@forge.softwareheritage.org/source/swh-docs.git (fetch)
origin  ssh://git@forge.softwareheritage.org/source/swh-docs.git (push)

@anlambert That feature is only enabled on swh-storage, and I think it's broken anyway.

@anlambert no, I don't have any such link - the top left of this page ( https://forge.softwareheritage.org/D1430 ) has "Accepted" and "Public" below the title of this Differential, but nothing else...

@zack Thanks for the answer.
It's not a blocker per se but I prefer to have a long term decision before moving the specs from different spaces, so for me it's a high priority.
It wasn't clear to me that it should be in the docs and that this is the long term decision.

Build is green
See https://jenkins.softwareheritage.org/job/DSTO/job/tox/377/ for more details.

Hi @mcv21 , did you try to land that diff directly from the web interface by clicking on the "Land revision" link on the top left part of that page ?

Currently, you can pass a filename as a query parameter to the content view of swh-web
(see https://archive.softwareheritage.org/browse/content/sha1_git:d0158ee2e79b461bf25b5b66e6778671c2114263/?path=xmlrpc.php
as an example).

According to Gandi documentation, if we switch to their LiveDNS feature, there will be no downtime.

In T1685#31076, @anlambert wrote:

@zack, I tried to handle that task but I do not have access to domains configuration from the Gandi interface.

@zack, I tried to handle that task but I do not have access to domains configuration from the Gandi interface.

Hm, no, I did that, but I still get the same permission denied message.

Tidy commit message.

Oh, I'm going to have to do arc diff --update first, aren't I? Sorry, not used this tooling before, and it's a bit confusing!

I tried (having done git rebase -i to tidy up the commit message, and then git merge), but get refused:

mv3@deskpro108655:/upstreams/SoftwareHeritage/swh-docs$ git push
X11 forwarding request failed on channel 0
Exception: You do not have permission to push to this repository.
fatal: Could not read from remote repository.

In D1430#31457, @mcv21 wrote:

[I think I can't merge this myself]

[I think I can't merge this myself]

Build has FAILED

• fixed conversion of datatype

Build has FAILED

• Fixed null exception in shortName

Build has FAILED

• Changed indexable and uid type to string

In T1683#31054, @moranegg wrote:

I need this decision for different specs, for example:

• Legacy software deposit
• Sparse / Metadata deposit (now in docs)
• Metadata workflow- How do we dill with software metadata (T1344)

Build has FAILED

• Changed bad response for phabricator lister

I need this decision for different specs, for example:

• Legacy software deposit
• Sparse / Metadata deposit (now in docs)
• Metadata workflow- How do we dill with software metadata (T1344)

Thanks for reviewing this diff, and apologies for my late reply and not closing it, I didn't find out how to close it when I first saw your message.

There are a million different file formats out there, why are we rendering Markdown and Jupyter notebooks and not something else?

I think we need to have a conversation about how we decide to add support for rendering specific file formats in the webapp.

Build is green
See https://jenkins.softwareheritage.org/job/DWAPPS/job/tox/402/ for more details.

Update: Check that hljs supports the notebook language prior calling the highlight function