different project names: remote project name vs taskwarrior project name

[adriangalilea]

I have some github projects that contain .

When I created the names of the projects locally I did transform them from: project: foo.bar taskwarrior name: foo_bar

(so they don't become a project and subproject)

But now bugwarrior creates the project foo with subproject bar

How can I associate remote repositories with local naming? (to prevent duplicated projects)

[ryneeverett]

I don't think this has come up before and I don't think there is a way to do this currently. We should probably automatically transform dots in project names to something else (underscore?) to avoid taskwarrior making that interpretation.

[adriangalilea]

I think that's a good idea, but perhaps is best to control the output project per repo.

Right now I'm using a whitelist for repos:

github.include_repos = e-id,self.fm,dotfiles,time-blocks,dtj,adriangalilea.com

it would be great to do something like:

github.include_repos = {"repo_name":"taskwarrior_project"},{...}

This way not only you prevent problems like mine but you also have granular control of where a repo ends in your internal system.

[ryneeverett]

I'm hesitant about that because I don't see much demand for granularity at the repo level. Most people are happy with granularity at the service level with field templates.

[adriangalilea]

I'm hesitant about that because I don't see much demand for granularity at the repo level. Most people are happy with granularity at the service level with field templates.

Fair enough, but my projects are complex and I do it solo, when I manage every aspect of a project I do like to isolate by context, so, my code will be under {project_name}.dev, and here is where I want my github issues, not under the general project where there may be, meetings, finances, graphics and what not.

Also I may want to have a few repos under the same project like: foo.front foo.back for frontend and backend repos(just an example)

I don't think repos are top level projects most of the times but an isolated part of a bigger project, I can totally solve this by designing a context which shows both the project that I created and the autogenerated by bugwarrior, but ideally I think it would make sense to put it wherever I designate it to.

If this is too complex don't bother. :)

If you where both freelance and had work projects and personal projects, wouldn't it be good to have them each separate by a top level work. personal. or bob.dev.foo bob.dev.bar (if doing several projects for a client)

Since this is a python project I may be eventually able to take a look and PR if you wish :)

[ryneeverett]

If I understand you correctly, field templates are exactly what you want. You'd need to use filters to make sure each section only captures the repos for a single project, which is a fairly common bugwarrior pattern (to avoid us having to support infinitely granular configuration). For each one you could then say, e.g.: github.project_template=work.clientbob.{{githubrepo}}.dev. Does that satisfy your use case?

[adriangalilea]

If I understand you correctly, field templates are exactly what you want. You'd need to use filters to make sure each section only captures the repos for a single project, which is a fairly common bugwarrior pattern (to avoid us having to support infinitely granular configuration). For each one you could then say, e.g.: github.project_template=work.clientbob.{{githubrepo}}.dev. Does that satisfy your use case?

Perhaps I'm missing something, but the template is for all the repos, so if in my github I have different clients and personal projects, can I address that and do work.bob.{{githubrepo}}.dev for a bunch of them then on the same account personal.{{githubrepo}}.dev, no, right?

[ryneeverett]

This is a bit difficult to explain partially because we use the term "service" to refer to both (a) our integration to a given third-party api (e.g. github) and (b) a given configuration section (e.g. [my_github]).

Yes, the template will apply to all repos in your service section (b) but you can have multiple sections for one service (a). You'd need to use filters (include, exclude, etc) to divide your repos between work and personal and could then assign the given project templates to each section.

[my_work_github]
service=github
github.exclude_repos=foo,bar
github.project_template=work.{{githubrepo}}.dev
[my_personal_github]
service=github
github.include_repos=foo,bar
github.project_template=personal.{{githubrepo}}.dev

Depending on your circumstances you may find that the current repo filtering abilities are insufficient for your needs, but I would prefer to add more powerful filtering features than a more granular project assignment if possible.

[adriangalilea]

This is a bit difficult to explain partially because we use the term "service" to refer to both ...

Hardest problem in computer science :)

I think the term should be account, profile or scope for (b).

And provider for (a)

Thank you for your help, I'll try that.

EDIT: forgot to mention, with that in mind it totally makes sense to convert . into _

EDIT2: this seems perfect, thank you so much @ryneeverett i got it 90% perfect already, and simply created a separate scope ;) for the repo with the . inside so we are good, only thing missing for it to be perfect is:

Field Name  Description Type
githubbody  Body    Text (string)
githubcreatedon Created Date & Time
githubmilestone Milestone   Text (string)
githubnumber    Issue/PR #  Numeric
githubtitle Title   Text (string)
githubtype  Type    Text (string)
githubupdatedat Updated Date & Time
githuburl   URL Text (string)
githubrepo  username/reponame   Text (string)
githubuser  Author of issue/PR  Text (string)
githubnamespace project namespace   Text (string)

From this options, I don't see none that provides only the reponame, is there the option to get just reponame somehow?

EDIT3: github.project_template=work.{{ githubrepo.split('/')[1] }}.dev this did the trick :)

Lastly, can I add the url that defaults to the description into the annotations?