-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
🚀 [Feature] Implement github workflow to publish data daily #16
Comments
Who maintains bundestag/gesetze? Who has pull/merge rights? There are lots of open pull requests which haven't been merged yet. One should first get the manual workflow running before trying to automate things. |
Most of the pull requests are either jokes, drafts or too large to review. Generating an up to date version from source is probably a better course of action. |
I sorta start taking the responsibility since people come to me and ask for the Repo. Tho I have nothing to do with it. My course of action is finding people who wanna do it. I have all the rights needed and can also propagate those rights. So if you wanna do the automatic push thingy, we can certainly make that happen rightwise. |
Anyone has an idea how to efficiently determine the changed laws since the last run? While it is easy for the scrapers (BGBl, BAnz, ...) since they are ordered by date, it is not so easy for the laws. |
I am wondering if it makes sense to use https://github.com/actions/cache for storing the json data instead of committing it to some repo as it is fully generated. @ulfgebhardt do you have an opinion here? |
I believe that it is worthwhile to store all data in a repo - that way we would make the changes of laws transparent and searchable. Why would we hide the actual content in some volatile cache? I do not really understand the benefits. But thats all just an opinion ;) |
I don't like the fact that tooling and data is mixed in this repository. Also using and updating the cache seems just easier. I also don't see any added benefit by storing this data as it is fully reproducible and verifiable by anyone. No strong objection, just my personal opinion. |
Tooling happens here: https://github.com/bundestag/gesetze-tools The data is not reproducable since the official websites do not provide a history, do they? |
I am talking about the intermediate JSON files stored in https://github.com/bundestag/gesetze-tools/tree/master/data. I agree that the final Markdown files should be committed via Git to the other repository. |
Ok then I missunderstood |
Hi! Sorry for being late to the party.
Don't cache, always publish.
Yes, we should strictly separate both. I had a quick look at |
This comment was marked as outdated.
This comment was marked as outdated.
Also it would be nice to have a small dummy version of the data repo, with all important structures at the latest version but much faster to clone. Or can I just pick an ancient commit? My hope is to make quick test runs for debugging that will probably produce wrong results but can give a preview of whether it would have worked when using the real data repo. |
🚀 Feature
Implement github workflow to publish data daily
Please help implement it - if you have the free time to do it we would solve a 3 year old problem which pops up every election year. Pinging capable and potentially interested people out of the blue: @Muehe @jbbgameich <3
User Problem
We would have plain text data here in github
bundestag/gesetze#55
Implementation
Use github workflows. See examples:
https://github.com/Ocelot-Social-Community/Ocelot-Social/blob/master/.github/workflows/publish.yml
https://github.com/gradido/gradido/blob/master/.github/workflows/publish.yml
https://github.com/mattia-lerario/Mentor-Application-Bachelor-Project/blob/master/.github/workflows/test.yml#L23
Additional context
src
The text was updated successfully, but these errors were encountered: