Issue Issues against "bad" feedstocks

[CJ-Wright]

There are some feedstocks that are listed as "bad". We might want to open issues against those to let the maintainers know that the feedstock isn't bot supported and how they could potentially help. Not all will have fixes (some upstreams we don't support) so we don't need to issue those, but others could be helped.

[viniciusdc]

I had an idea, what about create a json file on cf-scripts containing the feedstocks labeled as bad and then run a new function called open_bad_issues at these feedstocks ? (We can update that file every time we load the update_upstream_versions or something, cause we already look for the bad ones there)

[viniciusdc]

Maybe using the GitHub Cli to open the issues ?

[viniciusdc]

But just to be sure, we will be opening an new issue at the feedstock github page ? or at cf-scripts ?

[viniciusdc]

@beckermr or @scopatz sorry for bothering you, but what do you think ? I am thinking of something like this:

import json
import subprocess
import logging
import tqdm
import networkx as nx
from .utils import load_graph, executor

# conda-forge logger
logger = logging.getLogger("conda-forge-tick._bad_issues_request")

# prepare subprocess run command
def hub_create_issue(name: str, maintainer: any, bad_str: any) -> None:
    # TODO: maybe add a way to create the issue at the feedstock page, not inside cf-scripts
    title = f"Bad feedstock error on Conda-forge ({name})"
    label1 = "conda-forge"
    label2 = "bad"
    body = (
        "An bad error occurred when trying to update your feedstock information, "
        "please check any possible alteration made.\n I the project was discontinued please let us know.\n"
    )
    body += (
        f"You are receiving this error as an attempt to solve the current bad behavior "
        f"with the actual version of your feedstock, the problem raised {bad_str} as exception "
        f"for retrieving a new version, please look for further details at..."
    )

    assignee = f"{maintainer}"
    command = "gh issue create"
    command += f'--title "{title}" --body "{body}" --label "{label1}" --label "{label2}" --assignee "{assignee}"'
    try:
        # try GitHub cli issue creation
        subprocess.run(command)
    except Exception as ee:
        logging.info("")
    else:
        pass

def hub(graph: nx.DiGraph) -> None:
    # Open the data file with feedstock bad relating information
    with open("bad.json") as file:
        # bad_data is a dict containing info regarding the Node feedstock and it's bad status
        bad_data = json.load(file)

    _all_nodes = [t for t in graph.nodes.items()]
    revision = []
    for node, node_attrs in _all_nodes:
        with node_attrs["payload"] as attrs:
            if node in bad_data:
                revision.append((node, attrs))

    with executor(kind="dask", max_workers=20) as pool:
        for node, node_attrs in tqdm.tqdm(revision):
            with node_attrs["payload"]["extra"] as attrs_extra:
                # TODO: This will not work, we need to send a new issue for every maintainers not stack them
                # get maintainers list
                maintainers = attrs_extra.get("recipe-maintainers")

                # get bad occurrence
                bad = bad_data[f"{node}"]
                pool.submit(hub_create_issue, node, maintainers, bad)

if __name__ == "__main__":
    # load graph
    gx = load_graph()

    # load feedstock info and try issue request
    try:
        hub(gx)
    except Exception as e:
        pass

[viniciusdc]

I found this Github3 looking for our migrators codes, I will try to implement with this in mind. This way we can access the feedstock repo and create the issue there:

gh = github3.login(token=token)
issue = {
   'title': 'Documentation issue',
   'body': 'Missing links in index.html',
}

repository = gh.repository(user, repo)
repository.import_issue(**issue)

[viniciusdc]

@CJ-Wright I was thinking as you said about the API limits and continuous functionality what about insted of creating an issue, we recognize the bad feedstocks as we did with the new_versions and post it on a special part of conda-forge web service. This way when a bad feedstock appears it will goes right to the status page for the maintainer to have a lookof the problem (we could then change the issue creation for an email notification.) Or issuing the problem at the feedstock repo (if possible), but following a list at the webservices this way we would not bump at any problem with API limits.

1. bot recognizes the bad feedstock;
2. create a request for the web service containing the details;
3. the feedstock becomes queued at the web service data;
4. than a cron job (scheduled) run by 15 or 20 of these and create the necessary issues.