Skip to content
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

CI should submit a PR not merge to master with nightly script #31

Open
comountainclimber opened this issue Sep 3, 2018 · 5 comments
Open

Comments

@comountainclimber
Copy link
Member

Due to the impact of updating tokenList.json (neon-wallet depends on it) I propose that the nightly updates submit a PR against master rather than updating it without our approval. I noticed today that the data structure being returned from https://notifications.neeeo.org/v1/tokens completely changed (please see tokenList.json to see the huge difference). Luckily I turned off nightly updates completely but this is a perfect example of how a PR would be much better than blasting away master every night

@mhuggins
Copy link
Contributor

mhuggins commented Sep 3, 2018

There might be a little confusion here, as tokenList.json isn't a direct reflection of the neeeo.org API endpoint. It simply uses the list of tokens from there before fetching data from the RPC servers.

@mhuggins
Copy link
Contributor

mhuggins commented Sep 3, 2018

But I agree that submitting a PR is a less hardhanded solution here.

@comountainclimber
Copy link
Member Author

You are totally right the data structure is the same... Regardless I think submitting a PR is the safest option here

@comountainclimber
Copy link
Member Author

One potential solution I thought of was to keep everything as is but always merge into a develop branch rather than directly to master it would be the job of coz to cut the PR and merge into master but CI would never directly merge to master without us reviewing the diff

@mhuggins
Copy link
Contributor

Another possible solution here would be to never push if the size of the token list decreases. The only consideration is if something is added to the blacklist.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants