github-issues-import
github-issues-import copied to clipboard
Add more command line arguments
- [x] Add option to pass config file location as a command line argument. (f0fdcc11c337623bdd0d09bbcb582c34eda86557)
- [x] Prevent any actual Python code from being able to be included in the config file (cd9f6fdee82b7db9fd27f7c42f72b663a6a76bf3)
- [x] Allow the username and password to be passed in as arguments (f0fdcc11c337623bdd0d09bbcb582c34eda86557)
- [x] Optionally, prompt the user for a username and password if none is provided in the config file. (06b6910a22003fd56af0399decd100dda1fe8289)
- [ ] Allow for the option of using API keys rather than entering your password and username (as was done in https://github.com/IQAndreas/ghup/tree/dev-generate-token).
- [x] Allow the option to import closed issues. I would recommend the flags
--all
,--open
,--closed
, or the default for the type of import. - [ ] Add
--verbose
options - [ ] Add
--dry-run
option (this would have made all this debugging easier) - [x] Add
--ignore-labels
and--ignore-milestones
(48917c8b9ab3e5205c7886b8303b503d4bea7bea)
Old issue details (just changed this to a checklist in the main issue's body):
Pass config file location as argument
This allows the import script to be in one location, and the config file in another (for instance, in among the other repositories project files).
I may also need to prevent any "malicious" or "non-fitting" Python from being included in the file, but seeing as the same person who writes the config file in the same person who runs the script, I don't see this as being much of an issue.
Authorization
Perhaps allow the username and password to be passed in as arguments, or at least prompting the user for a username and password if none is provided in the config file (this is the most secure option, since it is never physically stored anywhere).
And allow for the option of using API keys rather than entering your password and username (as was done in https://github.com/IQAndreas/ghup/tree/dev-generate-token).
Allow the option to import closed issues
I'm not sure why this would be used, but it seems popular enough that several people have already incorporated such fixes into their own forks.
More arguments
- Add
--verbose
options - Add
--dry-run
option (this would have made all this debugging easier) - Add
--ignore-labels
and--ignore-milestones