Add status to issues tasks in tasks.yaml

[jayvdb]

When a task has max_instances: 1 and an issues URL , it can be annotated with an extra attribute to indicate the task status: available, claimed or completed.

Instance are exported as instances.yaml , and indicate whether the task is in progress or completed.

Completed issues are the easiest to work with.

In progress tasks are slightly more complicated because the publish instances are filtered to remove tasks still in early phases of the task lifecycle. See https://github.com/coala/community/blob/master/gci/students.py#L84

[himanshu1603]

Plese, assign me to this issue. Thanks!

[himanshu1603]

Plese, explain what is to be done in issue. I couldn't find .client, .config, .gitorg, .task in repo. Thanks!

[sks444]

I couldn't find .client, .config, .gitorg, .task in repo

These are the .py files in gci app
from .gitorg import get_issue means importing get_issue function from gitorg.py

Now for a task, you have to check what its max_instances, if it is 1 then you have to check if it has an issue related to it, if both conditions are satisfied then you have to add an extra attribute to the task as its status, i.e. available, claimed or completed.
This is what I have understood till now.

Try to understand the codebase of gci app, you will get this done 👍 ;)

[bkhanale]

Can I solve this issue? @jayvdb

[KVGarg]

@jayvdb I wasn't able to figure out that apart from adding status attribute to each task, do we need to make some additional changes in code where cleansing of instances is taking place ?

Since, each task is already having a status attribute with a value of 2, it is getting overwritten. Then, changes will also be made while cleansing the tasks. Also, I want to know what does status=2 implies ?

If we filter tasks that aren’t having status=2 while cleansing them, then the tasks.yaml will contain only those tasks that have status either COMPLETED, AVAILABLE or CLAIMED because the file is written again after cleansing the tasks. Will it be ok ?

Also, how to get GCI TOKEN to test the changes ?

[jayvdb]

You can not get a GCI TOKEN - it is admins only as it gives access to sensitive information about minors- tightly regulated by Google.

You need to use the deployed tasks.yaml , in https://github.com/coala/community/tree/gh-pages/static

re status=2, so my PR, which clarifies the status.

[KVGarg]

@jayvdb Should I make changes in both management commands - fetch_deployed_data and fetch_gci_task_data or in just one - fetch_deployed_data ?
and in which branch should I request PR "master" or "gh-pages" ?

[KVGarg]

There were some tasks which were having max_instances=1 but either there was no external url or the external url was not correct i.e. it was listing all the issues of the repository. So, won't be able to find task_state for those tasks.

[jayvdb]

The change needs to be in the gci/ modules on master, not in any management command as those are thin wrappers. ignore tasks without precise issue urls.

[KVGarg]

During execution of cleanse_gci_task_data the tasks as well as intances will be filtered. The tasks will annotated with an extra attribute state whereas instances will be filtered on the basis state having value COMPLETED.
After execution of cleanse_gci_task_data the files "tasks.yaml" and "instances.yaml" will be re-written by fetching the latest data.
In "tasks.yaml" the tasks who are having max_instances=1 and an issues url that task will have an extra attribute name state with 3 possible values "COMPLETED, AVAILABLE or CLAIMED".
After this, the "instances.yaml" will be re-written with only those instances whose referring task has an attribute state having value of COMPLETED.

Note - One drawback - there are atleast 204 tasks in deployed tasks.yaml every-time it fetches the data and api call is being made to get the status. Will take considerable amount of time depending upon internet connection speed