-
Notifications
You must be signed in to change notification settings - Fork 77
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
Continue to standardize process of creating a spreadsheet-based new layer #488
Comments
I think we can make a
Once an issue is made, we can write an interactive script (similar to create release script here: publiclab/PublicLab.Editor#617) which will ask for information like google sheet url, columns, etc in terminal and later make all the code changes automatically using some template files and will use Now after running this script, the first-timer contributor just has to make PR. What do you think @jywarren @ebarry ? |
I think i understand, and i think i like it. @bhamster07, please follow along here :) I'm going to try to recap: For the person contributing data, they would have to:
(THEN ROBOTS DO STUFF, including creating a first-timers-only issue in this repo with next steps) Then, a new contributor would:
Then the regular processes of our website maintainers take the next steps: review the PR, merge, republish the website, and the layer will then be visible in the layer palette on any map on the website, including on /map. Is this correct? |
Absolutely correct @ebarry 👍 💯 |
Just circling back to say that @bhamster07 who would be a data contributor has said that "Workflow definitely seems doable, straightforward and easy 👍" |
@ebarry @jywarren ...few points:
|
This sounds great, i wonder if the level of integration is a bit deep in that perhaps a direct request from rails to the Octokit API would be a brittle thing to maintain - API integrations are tough to test for. What if we made a more lightweight workflow which involved an issue template, which then could be manually copied into a FTO template with ALL_CAPS_REPLACEABLE_TEXT strings corresponding to, for example, the spreadsheet URL, the name of the layer, the color of the markers? This could be automated in a later step but it would be more robust to failures - it wouldn't depend on the Octokit/Rails integration and if a script or bot failed, it's pretty easy to continue doing it manually, so the breakage wouldn't be a show-stopper. Open to other ideas - but just thinking about who maintains the bot, you know? ❤️ 🤖 what do you think? |
Correct @jywarren doing manually is straightforward, but one will need to make FTO issue manually from template issue everytime new layer is requested. I was reading octokit api to create issue, it is simply a wrapper over github api and needs title, description, and gh token as params. So this should not break easily. For the script, which will do all changes in the repo automatically for adding new layer that I agree is more prone to break if we change folder structure or maybe some package upgrade. Anyways as a backup we should definitely document how to do all this manually 👍 💯 |
So there is no bot actually in above flow, we are just making a new github account and using its personal access token, which we will pass to octokit wrapper function to create FTO issue 😄 |
Let's start by making the template, and go through it manually once, then we can automate? But would this Octokit script be part of the |
I guess i might prefer if the script could be in JS in this repo, do we have the option for JS vs. Ruby w/ Octokit? |
Okay sure we can first document everything that needs to be done if done manually, i.e from format of excel sheet to making FTO to making layer and PR. Yes as mentioned here #488 (comment) So for now we should not go ahead with either of the 2 scripts? which are:
|
Since (2) will make the system work (even in a reduced way) but (1) won't by itself, i guess let's start with (2)! |
This comment has been minimized.
This comment has been minimized.
I was brainstorming on this issue and I have a nice way to bridge the gap between opening the issue and running the script. So, we can trigger the running of script using the GitHub actions, I have created an example workflow here https://github.com/daemon1024/issue-action-script-run. This just logs the issue description in the action. This wouldn't need a server dependency while also maintaining the manual ecosystem if this fails. Let me know if this could be an addition the process would be happy to propose this in detail. Update : |
We have layers that drive from google spreadsheets -- like the PFAS layer:
https://github.com/publiclab/leaflet-environmental-layers/blob/main/src/pfasLayer.js
we should improve the workflow for this, as in #135 - for specifically Google Spreadsheet-based layers
@kevinzluo made an awesome generic utility for this at #105 which we could build on!
Example spreadsheet we could link to in the docs: https://docs.google.com/spreadsheets/d/1biyMqC4pk4pezG6EuJ6oSXSMBDlZFxfpleqv5BlTSaM/edit#gid=0
The format of the spreadsheet should be:
It'd look like this:
The text was updated successfully, but these errors were encountered: