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

deletes and recreates todos every run (gitlab.com) #552

Closed
abderrahim opened this issue Apr 4, 2018 · 1 comment
Closed

deletes and recreates todos every run (gitlab.com) #552

abderrahim opened this issue Apr 4, 2018 · 1 comment

Comments

@abderrahim
Copy link
Contributor

Every time I run bugwarrior-pull, it marks my todos as completed and creates new ones.

Curiously, this only happens with gitlab.com but not with gitlab.gnome.org.

@abderrahim
Copy link
Contributor Author

I tried to investigate this, and it seems to be caused by taskwarrior itself. The when the gitlabnumber field is big, there are no matches. For instance 9844164 triggers this behaviour but 4819 doesn't. It looks like an overflow.

Wrestling with it further, I got this error

The value '10420777' is not a valid numeric value.

Which confirms the todo numbers on gitlab grew larger than the numeric type of taskwarrior. (And there is a bug in taskwarrior in that it doesn't notice it soon enough).

I'll open a pull request shortly making the field of type string instead. It's not like it's really numeric, it's just an ID that happens to be a number. The drawback is that it will make bugwarrior delete and recreate all todos for all people once (even those using instances not yet affected).

Another problem is that people may need to update the UDAs in their .taskrc.

abderrahim added a commit to abderrahim/bugwarrior that referenced this issue Apr 20, 2018
…y#552)

The gitlabnumber's of todos on gitlab.com have grown beyond the limits of the
numeric type, and that may happen on other instances too.
abderrahim added a commit to abderrahim/bugwarrior that referenced this issue Apr 20, 2018
…y#552)

The gitlabnumber's of todos on gitlab.com have grown beyond the limits of the
numeric type, and that may happen on other instances too.
doronbehar added a commit to doronbehar/bugwarrior that referenced this issue May 7, 2019
…o develop

* 'develop' of https://github.com/ralphbean/bugwarrior:
  Fix gitlab test
  Gitlab config owner filter
  Gitlab config membership filter
  Set default priority in trello test.
  Don't hardcode priority for trello cards
  Revert "Make pull requests a top priority."
  Fix default_priority option
  Gitlab request projects in simple mode
  Fix when request single project for include_repos
  Update gitlab service to correct project request
  Update python3 versions.
  Fix tests and docs for GothenburgBitFactory#557.
  gitlab: make the gitlabnumber UDA a string (fixes GothenburgBitFactory#552)
  code simplification based on PR feedback
  optionally set bug to "started" when assigned
  Raise proper exception when trying to handle data_path on config
  Check if taskrc file exists before trying to load config
  Add the ability to exclude Github pull-requests
  Unpin futures to avoid dependency conflicts
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants