Generate repos.json via workflow

[willuhmjs]

Uses a GitHub Action to automatically update repos.json with a Deno script. Blazing fast and super safe!

Fixes #51.

[willuhmjs]

@ctubbsii What is code.json used for, and what GitHub API endpoint is used to generate it?

[ctubbsii]

@ctubbsii What is code.json used for, and what GitHub API endpoint is used to generate it?

That file is used to feed into the software inventory at https://code.gov/ . You can read more about it there, but I think one of the main goals is to make software that is funded and produced by one government agency available to others, to promote cost savings across the government, rather than different agencies waste taxpayer funds to reinvent existing solutions.

As for how it is produced, there are probably some tools at https://code.gov/, but I don't know if we're using that or some other custom tools. I would have to investigate. In the past, my part had been to help format the files that were produced by somebody else who was responsible for generating them (as in, for example, #36). I've used pygithub in the past... I'm not sure which endpoints we'd need for this, though. I'd check at https://code.gov/ first to see if there's good existing tools for producing the json.

[willuhmjs]

Since the code.json schema is maintained by the GSA, I have limited the scope of this PR.

[ctubbsii]

@willuhmjs I appreciate your enthusiasm to help out here, but we have a lot of constraints about the kinds of things we can trust to be added here, and I think we're going to need to review our own scripts for generating updates here, because have a lot of additional considerations to make that you can't get from the GitHub API (like the supplemental repos.json file I mentioned in the comment below).

[ctubbsii]

Sorry, but running 3rd party GitHub Actions tasks is basically a non-starter... for the same reasons we couldn't approve of the binary images. We can't really trust 3rd party code running on our repos, especially with permission to alter their contents, as this would necessarily need to do.

The code that would need to run would have to be included in this repo, or use standard GitHub.com created actions (or equally respected and widely used, like the ruby/ actions).

[willuhmjs]

What do you consider as "equally respected and widely used?" Would Node.js work instead of Deno? If so, I can easily modify the code to use Node.js instead.

[ctubbsii]

Ideally, all the code that runs on the project and alters the project is contained within this repo. The GitHub Actions could run a python script checked into this repo, for example. I would prefer basic shell scripts (bash) or python, because we need to keep it to something that most developers could maintain, and not do anything too niche. Lowering the barrier to maintenance is the best way to ensure that we'll be able to keep this maintained, when people switch jobs, move positions, prioritize other projects, etc.

[ctubbsii]

There are a lot of changes to this file. This file is intended to supply additional information about our publicly available software that is published to other locations, so that the information can be still be collected and placed in the generated code.json file. Removing those entries should not be done at all.

[willuhmjs]

Modifying the script to fetch from other locations wouldn't be difficult to do. What are the other sources?

[ctubbsii]

@willuhmjs The repos.json is supposed to contain the metadata for that. But, I'm not sure how that file itself is updated. This is something we would need to do internally. I don't think this is something an outside contributor can contribute.

[ctubbsii]

I think I need to close this PR for now. I do not think that we're going to be able to keep this updated with anything contributed from outside. We have used a python script internally to keep these things up-to-date. I need to work with the internal folks who have run that to get that added to this repo. Once that is done, then we can automate it. Until then, we should leave it as is.