Remove ability to publish via github

[bloodearnest]

We want to stop this as soon as possible.

We need to:

a) build a list of active workspaces still pushing releases to github
b) convince them to stop/migrate to job-server.
c) turn this off.

[sebbacon]

In terms of (b) - whoever picks this up should enlist the help of researchers who may know the individuals concerned; and @amirmehrkar in case there are problems convincing people.

I suggest we pick an arbitrary date when we are going to turn off access (say in about 6 weeks) and arrange with each individual still using the old system a handover meeting where we describe how to do it the new way. Or - perhaps more efficient - screen-record the first handover meeting and then just share that in the first instance.

[sebbacon]

In terms of (a) and (c), @bloodearnest should be able to advice - Simon, if you get a chance, perhaps post some pointers here?

[ghickman]

@bloodearnest – do you think workspaces with jobs created in the last 6 months is a reasonable measure of active here?

[bloodearnest]

Possibly, but I think we need github activity here.

A possibly proxy for that is /d/osrelease/log.txt, which has logs going back to Nov 2021

[bloodearnest]

A lot of those are internal projects, interestingly

[ghickman]

One repo has already moved over: https://github.com/opensafely/immunosuppressant-meds-research

It used to have a release-candidates branch but that's gone now, and the PRs (eg) don't link to commits or files any more. Do we need to anything further for this one?

[ghickman]

Repos to deal with:

• antipsychotics-prescribing-during-COVID-19
• covid-vaccine-neuro-research
• covid-ve-change-over-time
• hh-classification-research
• immunosuppressant-meds-research (moved already)
• long-covid-descriptive-research
• os-sch-children-2021 (archived)
• principle-inhaler-uptake
• SGTF-omi-research
• sro-gastro
• SRO-smr

Has Reports

• comparative-ve-research
• covid-vaccine-preliminary-study (via another repo so Lisa is going to release to job-server as part of her current flow and see how she gets on)
• mechanical-valve-anticoag
• SRO-Measures

[bloodearnest]

os-sch-children-2021 has been archive, possibly some of the others have too.

This raises an interesting question. Should we block releasing to an archived workspace?

[ghickman]

I've checked job-server, all of these repos have at least one active (non-archived) workspace, apart from os-sch-children-2021.

We should definitely discuss releasing to an archived workspace, but I don't think we need to block this ticket on that discussion.

[ghickman]

Reports will be able to use outputs released to job-server once opensafely-core/reports#291 is in.

[ghickman]

covid-vaccine-neuro-research is right at the end of their study (they're responding to reviewers and just about to re-submit). They're going to stick with releasing to GitHub rather than move over since they're wrapping up.

[ghickman]

All workspaces for the list of repos above have been switched to outputting to job-server or have a reason not to move.

[sebbacon]

Epic work!

...or have a reason not to move

Does that technically mean that ability to publish via github is still "switched on"?

[ghickman]

@sebbacon – yes. I've only looked at repos in the list above (so anything which has pushed to github in the last ~6mo). A couple of studies are just wrapping up so it made sense to not disrupt them when they're so close to being done.

Should we leave this ticket open until they're over the finish line?

It's just occurred to me that we need something to track the removal of functionality from this tool too, should that be this ticket?

[sebbacon]

I don't mind - but we do need some kind of ticket to track that we need to turn it off -- how to tell when we can do that, who to chase, and what to do. If you open a new one, please highlight to to me so I can prioritise. Thanks!

[ghickman]

Yep, good point, I'll reopen this one, so close!

---

ToDo:

• Chase wrapping up repos (George: get the names of those)
• Remove GitHub functionality from osrelease
• Lower request size in github-proxy to ~2k

[bloodearnest]

I would consider this done when we can reduce the request size in the github-proxy down to maybe ~2k (which is enough to clone, but not enough to push).

That's what will improve our security posture.

[lucyb]

Superseded by #54

[ghickman]

@lucyb – I don't think it is, my latest comment has a todo list with items that #54 doesn't cover.

[lucyb]

Apologies @ghickman , I'll reopen it.