aicoe / aicoe-ci Goto Github PK

Is your feature request related to a problem? Please describe.
if tekton tries to merge some PR, it should the do-not-merge labels

As User of Thoth CI,

I would like to see coala errrors as comment in the PR so that I can take actions faster.

Is your feature request related to a problem? Please describe.
We should start using Py38 for checks run by tekton.

aicoe-aiops/sync-pipelines#6
aicoe-aiops/sync-pipelines#7

Is your feature request related to a problem? Please describe.
As per discussion with @harshad16 the images built from PRs are pushed to destination Quay repos and never removed. This might result in many "useless" tags in the repo

Describe the solution you'd like
We discussed 2 potential solution which could be combined for one super smart solution

1. Delete the image tag after PR is closed
2. Delete the image tag after a release containing the change is created

Ideally, the 1. would be configurable and 2. would be happening always, but either of these is good enough solution on its own

isnt https://github.com/thoth-station/thoth-ci/blob/e5d833f8ec81ce92e6db322a16661ae2fbdc9261/tasks/pytest-checks.yaml#L74 taking the exit code of line 73 into account? which is set. But it should eval the exit code of the python3 call...

Get a prow installation to serve the pull request interaction for aicoe.
Ideally would like an instance of prow for whole aicoe GitHub projects.

Init-step:

• Start with deployment on a quick lab cluster for a sample of the thoth-station repository.
• Extend it for other repositories of thoth-station.
• Extend it for whole aicoe repositories.
• Integrate Prow so it can run Tekton Pipelines as a Job

References:

• config file
• prow deployment
• prow openshift deployment

Describe the bug

on an issue opening, the pipeline has processed the pullrequest pipeline.

{"level":"info","ts":1598023217.8816428,"caller":"pullrequest-init/main.go:56","msg":"RUNNING DOWNLOAD!","resource_type":"pullrequest","mode":"download"}
{"level":"info","ts":1598023217.881683,"caller":"pullrequest/api.go:54","msg":"finding pr","resource_type":"pullrequest","mode":"download","provider":"github","owner":"opendatahub-io","repo":"s2i-lab-elyra","pr":"2"}
finding pr 2: Not Found
{"level":"fatal","ts":1598023217.9877696,"caller":"pullrequest-init/main.go:60","msg":"finding pr 2: Not Found","resource_type":"pullrequest","mode":"download","stacktrace":"main.main\n\tgithub.com/tektoncd/pipeline/cmd/pullrequest-init/main.go:60\nruntime.main\n\truntime/proc.go:203"}

http://tekton-dashboard-tekton-pipelines.apps.thoth01.lab.upshift.rdu2.redhat.com/#/namespaces/thoth-ci/pipelineruns/aicoe-pipelinerun-fxmqr

Is your feature request related to a problem? Please describe.
It might be handy to receive a notification if a new tag release has been pushed to quay or pypi by a tekton pipelinerun

Is your feature request related to a problem? Please describe.

It would be great if we could automate testing of micropipenv for each PR. As micropipenv is on a different layer, it might be tricky to run the CI with the same configuration as for the other components of Thoth.

Describe the solution you'd like

Execute micropipenv testsuite using tox. We also need Python interpreters in different versions to verify the correctness. See thoth-station/micropipenv#72 for more info.

Describe alternatives you've considered

As micropipenv is not tightly bound to Thoth itself, we could use centos CI or travis to execute the test suite. As the requirements are pretty straightforward we could let these solutions run the CI not to maintain big changes on our side.

Hey, Kebechet!

Create a new major release, please.

Describe the bug
A redeliver pipeline was triggered in the metrics-exporter.
thoth-station/metrics-exporter#546
After the successful image build, the output comment on the issue has displayed the wrong link.

Expected behavior
Get a correct link in the output comment.

Screenshots

Is your feature request related to a problem? Please describe.
tag-release should wither out a container image to a repo or a python module to an index, the configuration should be part of the git repository, credentials be part of thoth-ci argo application.

Describe the bug
The pre-commit check sometimes runs into the gitlab resolve host issue:

[INFO] Initializing environment for git://github.com/Lucas-C/pre-commit-hooks.
[INFO] Initializing environment for git://github.com/pre-commit/pre-commit-hooks.
[INFO] Initializing environment for git://github.com/pycqa/pydocstyle.git.
[INFO] Initializing environment for https://github.com/pre-commit/pre-commit-hooks.
[INFO] Initializing environment for https://github.com/pre-commit/mirrors-mypy.
[INFO] Initializing environment for https://github.com/psf/black.
[INFO] Initializing environment for https://gitlab.com/PyCQA/flake8.
An unexpected error has occurred: CalledProcessError: command: ('/usr/bin/git', 'fetch', 'origin', '--tags')
return code: 128
expected return code: 0
stdout: (none)
stderr:
    fatal: unable to access 'https://gitlab.com/PyCQA/flake8/': Could not resolve host: gitlab.com
    
Check the log at /tekton/home/.cache/pre-commit/pre-commit.log

Is your feature request related to a problem? Please describe.
releases are created in pypi properly, but it would be great if a release would be created in Github (like here) rather than just a tag.

Describe the solution you'd like
Once a pypi release is created, create a release in the github repo.

Describe alternatives you've considered
Current alternative is to manually create a release, I think this can be automated.

As Thoth-CI
I want to run a Tekton Pipeline
so that I build all solver container images
and so that I push them to quay as v

Goal
Have a tekton pipeline run on each tag of git repository

Acceptance Criteria

• review how integration with build-wathcer works

References
https://quay.io/repository/thoth-station/solver-...
https://github.com/thoth-station/solver

As User of Thoth CI I would like to have direct link to the Pipeline Run for my PR when I click on details button.

Is your feature request related to a problem? Please describe.

It would be great if we move away from setup.py test command used to trigger unit tests. As an alternative, we could use nox or tox (used in many Python communities).

Describe the solution you'd like

Have a solution that seamlessly integrates with Pipfile and does not require maintaining setup.py (some components does not need it at all).

Let's have a spike which tooling can be used to trigger and maintain the testsuite:

• check tox
• check nox
• come up with a sample repo that triggers the testsuite using nox
• come up with a sample repo that triggers the testsuite using tox
• make sure the sample repo uses Pipfile and respects its dev dependencies that are required to be installed when running the testsuite
• think about possibly abstracting away the configuration (moving it to CI) so that users do not need to provide tox/nox config file for triggering the testsuite (unless they want to override the default behavior)

References

• https://pypi.org/project/tox/
• https://pypi.org/project/nox/
• wntrblm/nox#159
• https://github.com/tox-dev/tox-pipenv
• ...

Is your feature request related to a problem? Please describe.
AICoE-CI runs tests on PRs, would it be possible to upload the test coverage reports to the Codecov.io? This integration is available in other CI solutions like Travis, Jenkins, Circle-CI, Github Actions.

Describe the solution you'd like
After each test run, allow for optional (?) coverage report upload to codecov.io. The CODECOV_TOKEN can be stored in repository secrets and pulled by AICoE-CI during the test env setup.

Describe alternatives you've considered

Additional context
Codecov.io in connection with Sourcegraph browser extension allows for much easier and faster review process and code health maintenance. It would be nice if we can use those tools in AICoE as well.

Is your feature request related to a problem? Please describe.
We should not use any colored output if we copy it to a pr comment, GitHub does not support that (or in s different way)

https://github.com/thoth-station/thoth-ci/blob/e5d833f8ec81ce92e6db322a16661ae2fbdc9261/tasks/open-issue.yaml#L37-L38

Is your feature request related to a problem? Please describe.
If a pipeline is run for the second time on the same PR, the status of the first run is still shown until the pipeline resets the status, this is confusing.

Describe the solution you'd like
each pipeline run shall set the status to pending as one of the very first tasks

Describe alternatives you've considered
n/a

Additional context
n/a

Is your feature request related to a problem? Please describe.
I think we call all the results of task "checks", should we rename the /retest comment to /recheck ?

Describe the solution you'd like
s/retest/recheck/g

Describe alternatives you've considered
na

Additional context
na

As Thoth-CI
I want to run a Tekton Pipeline
so that I build all solver container images
and so that I push them to quay as v<git-tag>

Goal
Have a tekton pipeline run on each tag of git repository

References

• https://quay.io/repository/thoth-station/solver-....
• https://github.com/thoth-station/solver

Acceptance Criteria

• new v0.6.0-dev release on push to master branch of git
• review how integration with build-wathcer works

Is your feature request related to a problem? Please describe.
The amount of repositories derived from https://github.com/aicoe-aiops/project-template (and probably https://github.com/thoth-station/template-project ) grows... It would be nice if we can use AICoE-CI to propagate the template changes and update the children repositories, so they all are in sync with the template and we don't maintain "multiple versions" of the same standard.

Describe the solution you'd like
Fetch and rebase children repository when the template repo's HEAD is updated. To get the parent template repository from Github REST API use Accept: application/vnd.github.baptiste-preview+json header:

$ curl -s -H "Accept: application/vnd.github.baptiste-preview+json" https://api.github.com/repos/aicoe-aiops/sync-pipelines

{
  "id": 276931347,
  "node_id": "MDEwOlJlcG9zaXRvcnkyNzY5MzEzNDc=",
  "name": "sync-pipelines",
  "full_name": "aicoe-aiops/sync-pipelines",
   ...
  "template_repository": {
    "id": 207786768,
    "node_id": "MDEwOlJlcG9zaXRvcnkyMDc3ODY3Njg=",
    "name": "template-project",
    "full_name": "thoth-station/template-project",
    "private": false,
    ...
  }
  ...
}

Describe alternatives you've considered
Each repo maintainer would have to keep track of the template updates manually. That may cause troubles when the template updates introduces changes later used in other automation which relies on these changes - like when the repo is being build into a s2i image, or in a case when we would like to propagate changes to the repo layout (like AICoE/internal-data-hub#9 ), etc.

Additional context
Merging from unrelated history (template may have unrelated history) may be dangerous, but I think automating these updates may be beneficial in a long run. Also auto approval of the PRs in children repos should not be expected here.

What do you think ? @goern @durandom @harshad16

Is your feature request related to a problem? Please describe.
We want our deployments to auto-pick up the newly built and released images. AI-CoE CI can successfully release, build and publish the image on quay. The image is properly tagged as the released version. We would like the CI to tag the quay image as the latest as well

Describe the solution you'd like
Tag the same image as was released as vX.Y.Z as latest as well.

Describe alternatives you've considered
n/a

Additional context
n/a

Describe the bug
A PipelineRun is triggered on closing a PR.

Expected behavior
the build pipeline should not be triggered

Additional context
Maybe some other pipeline can be triggered (later).

Describe the bug
I would like to know why build failed

To Reproduce
Steps to reproduce the behavior:

1. Create git tag in repo and look at Tekton Pipeline Run
2. Go to logs for build Task

Expected behavior
Build is successful and new image is available on Quay

Screenshots

Additional context

Describe the bug
I'd like to have the Tekton Dashboards (publicly) accessible, currently I can't access them, even though I'm on VPN. Is this an outage?

To Reproduce
Steps to reproduce the behavior:

1. Go to AICoE/idh-manifests#12
2. Scroll to PR checks
3. See failing check and click the "Details"
4. Site can't be reached

Expected behavior
View the check results

Screenshots

Describe the bug
pull request built failed to use the configuration set in the repo .aicoe-ci.yaml config file and is building on default behaviour.

Additional context
Looking at this pipeline (http://tekton-dashboard-tekton-pipelines.apps.thoth01.lab.upshift.rdu2.redhat.com/#/namespaces/thoth-ci/pipelineruns/aicoe-pipelinerun-zgcjp)

/usr/local/bin/s2i build . quay.io/thoth-station/s2i-thoth-ubi8-py36:v0.14.3 --env UPGRADE_PIP_TO_LATEST=1 --env WEB_CONCURRENCY=1 --env THOTH_ADVISE=0 --env THOTH_ERROR_FALLBACK=1 --env THOTH_DRY_RUN=1 --env THAMOS_DEBUG=0 --env THAMOS_VERBOSE=1 --env THOTH_PROVENANCE_CHECK=0 --loglevel=0 --as-dockerfile /gen-source/Containerfile
Application dockerfile generated in /gen-source/Containerfile

its using wrong base image.

let have the pipeline not respond if a /-command is unknown

Is your feature request related to a problem? Please describe.
Keeping things up to date is always a struggle. AICoE-CI can help with python dependencies and such. I think it would be nice to be able to keep pre-commit hooks up-to-date as well.

Describe the solution you'd like
AICoE-CI would create automated PRs if pre-commit hook is updatable. This can be checked/performed via pre-commit autoupdate. Running this command results in updated .pre-commit-config.yaml which can be submitted as the PR.

For example pre-commit autoupdate in thoth-station/template-project results in:

$ pre-commit autoupdate
Updating git://github.com/Lucas-C/pre-commit-hooks ... updating v1.1.1 -> v1.1.9.
Updating git://github.com/pre-commit/pre-commit-hooks ... updating v2.0.0 -> v3.3.0.
Updating git://github.com/pycqa/pydocstyle.git ... updating 4.0.1 -> 5.1.1.
Updating https://github.com/pre-commit/pre-commit-hooks ... updating v2.3.0 -> v3.3.0.
Updating https://github.com/pre-commit/mirrors-mypy ... updating v0.770 -> v0.790.
Updating https://github.com/psf/black ... updating 19.10b0 -> 20.8b1.
Updating https://gitlab.com/PyCQA/flake8 ... updating 3.7.8 -> 3.8.4.

$ git status --short
 M .pre-commit-config.yaml

Describe alternatives you've considered
Manual updates

Additional context
Pre-commit hook updates are not that fast pacing and are not part of the critical chain of the actual codebase, so priority of this is kinda low.

Is your feature request related to a problem? Please describe.
Currently Sesheta will add a comment stating:

Successfully built and delivered the image.

Describe the solution you'd like
I would like the comment to contain also the url of the built image, ideally in a form of clickable link:

Successfully built and delivered the image quay.io/thoth-station/s2i-minimal-notebook:v0.0.5

(source: Successfully built and delivered the image [quay.io/thoth-station/s2i-minimal-notebook:v0.0.5](https://quay.io/thoth-station/s2i-minimal-notebook:v0.0.5))

Since Quay will automatically redirect the image URL to console URL, so user can easily get to a list of tags and see that everything is as expected

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Describe the bug

STEP-OC-CREATE-IMAGE

Error from server (NotFound): imagestreams.image.openshift.io "SrcOpsMetrics-89" not found
The ImageStream "SrcOpsMetrics-89" is invalid: metadata.name: Invalid value: "SrcOpsMetrics-89": must match "[a-z0-9]+(?:[._-][a-z0-9]+)*"

To Reproduce
Steps to reproduce the behavior:

1. open PR in a repo with an mixed-case name

Expected behavior
repo name is .to_lower()

Describe the bug
Currently the image tag generated by /deploy command is just a PR number. That might get a bit confusing with potentially arbitrary versioning schemes and also looks "weird"

To Reproduce
Tag name is just a number

Expected behavior
The tag should be ideally a bit more descriptive something like - pr-XX (e.g. pr-56) or dev-XX (e.g. dev-56)

Is your feature request related to a problem? Please describe.
Tekton Feature to run a conftest task, so that we validate PR with it.
The validation will be based on some Open Policy Agent policies.
We need some policies, like https://github.com/thoth-station/thoth-application/blob/master/policy/deployment.rego

Describe the solution you'd like
https://github.com/open-policy-agent/conftest/blob/master/examples/tekton/taskrun.yaml

Additional context
Related-to: AICoE/aicoe-cd#29 (comment)

create a tekton task that could use one branch from a repo and gatsby-cli to generate static html/... and commit this to the gh-pages branch of the same repo.

Hey, Kebechet!

Create a new major release, please.

after tag-publish-pypi-run we should notify the devops channel that we uploaded (or not) to pypi

Describe the bug

Tekton is sometimes not delivering back its status thoth-station/common#879 pytest is still pending, but http://tekton-dashboard-tekton-pipelines.apps.thoth01.lab.upshift.rdu2.redhat.com/#/namespaces/thoth-ci/pipelineruns/aicoe-pipelinerun-t6c6n looks like it is successfully finished.
some for the pre-commit check http://tekton-dashboard-tekton-pipelines.apps.thoth01.lab.upshift.rdu2.redhat.com/#/namespaces/thoth-ci/pipelineruns/aicoe-pipelinerun-t6c6n

Expected behavior
The status should change from the pending state after corresponding pipelines have executed.

Additional context
The issue feels like the discrepancies between direct status update through API request and status update through the tekton status output method.

Describe the bug
it seems that pipelines are not running for AICoE repos, see AICoE/sefkhet-abwy#32

OCP cluster is on 4.3 with OpenShift Pipeline Operator, ArgoCD should be reconfigured to deploy to that cluster, rather than thoth01

/kind feature
/priority critical-urgent
/assign @harshad16

Is your feature request related to a problem? Please describe.
For some repositories I always run /deploy to get image pushed to quay.io to be able to easily test the changes. I

Describe the solution you'd like
I'd like to be able to set a configuration which will result for the pipeline to always push the PR build to registry without the need to add /deploy comment

e.g.

push_on_pr: true

Ideally, the pipeline should also comment on the PR when the push is done and it should provide a link to the new image

Describe alternatives you've considered
Keep using the /deploy command. Although possible, it is not a good user experience

Additional context

The image should be also deleted from the registry when the PR is merged to make sure the image repository is not clutterred (see #52)

As ...
I want to run a tektoncd pipeline,
so that I can continuously deliver ODH container images to quay.

Story Points: 13
Key-Result: NOKR

Goal
build all jupyterhub app stack (notebook) images via a tektoncd pipeline

Acceptance Criteria

• jupyterhub image is published automatically on git tag event
• jupyterhub-img is published automatically on git tag event
• notebook-images are published automatically on git tag event
• tektoncd pipeline is hosted on PSI
• tektoncd pipeline artifacts are published on github

References

• https://github.com/opendatahub-io/odh-manifests/blob/master/jupyterhub/jupyterhub/overlays/build/jupyterhub-buildconfig.yaml#L12
• https://github.com/opendatahub-io/odh-manifests/blob/master/jupyterhub/jupyterhub/overlays/build/jupyterhub-dh-buildconfig.yaml#L11
• https://github.com/opendatahub-io/odh-manifests/tree/master/jupyterhub/notebook-images
• https://github.com/opendatahub-io/odh-manifests/issues/37
• https://gitlab.com/opendatahub/opendatahub-operator/-/issues/218
• kubeflow/kubeflow#4789
• https://github.com/opendatahub-io/odh-manifests/issues/43

Shall we try and test if registry.access.redhat.com/ubi8/ubi-minimal is suitable for steps like https://github.com/thoth-station/thoth-ci/blob/3087df33cd932ca6de0b820a98a8e1b9b4294f9f/conditions/retest-comment-check.yaml#L17

Is your feature request related to a problem? Please describe.
thoth-station/micropipenv#101

Describe the solution you'd like
AICoE CI Pipeline should run tox/pytest, in the best case we can reuse tasks from some catalog.

Let's integrate our s2i task with https://hub-preview.tekton.dev/

Managing s2i builder images in https://github.com/thoth-station/graph-sync-job/blob/master/.aicoe-ci.yaml#L5 and https://github.com/AICoE/aicoe-ci/blob/master/tasks/resource.yaml#L12 seems to be a not that good solution. Can we simplify it?

Is your feature request related to a problem? Please describe.
The pipeline only provides explicit tags, but sometimes it would be useful to be able to have the new build also tagged with a custom tag (e.g. latest or released)

e.g. in "multi-stage" builds, where you have multiple images depending on each other - like s2i-scipy-notebook -> s2i-minimal-notebook - I would like to be able to use tag released for the base image of s2i-scipy-notebook so that I am sure I always build on top of the latest git release (but at the same time I may not want to use latest which maybe points to master)

Describe the solution you'd like
Provide an option in .aicoe-ci.yaml which allows user to define a custom tag (e.g. custom-tag: released or custom-tag: latest).

If this is not null then the pipeline will build image based on new git release (e.g. v0.0.z) and also tag with the given tag

This can also be used to make sure the latest tag points to the latest release, but since latest is kind of messy in the container image world, it should not be assumed this "latest" tag name has always the value latest hence custom-tag.

Describe alternatives you've considered
Current alternative (AFAIK) is to manually tag the image after release, which is error prone (user can easily forget to do it) and, well, manual

Is your feature request related to a problem? Please describe.

AICoE CI works flawlessly. A minor thing - sometimes I struggle with PRs that result in a failed pytest/pre-commit run. When such issues are reported by AICoE CI, I fix them and commit changes to the pull-request. Sometimes I need to double-check if all is green or I need to issue /retest.

Describe the solution you'd like

If all the pipeline checks are successful, a message by bot could be sent indicating all the tests passed.

Describe alternatives you've considered

Send the message for each check (might be redundant?) or keep the solution as is if the request is too complex to implement.

Describe the bug
I tagged v0.1.0-dev for https://github.com/thoth-station/unresolved-package-handler/tree/v0.1.0-dev after making sure the repo on quay was created and correctly set. No release has been created on quay.

To Reproduce
Steps to reproduce the behavior:

1. Go to thoth-station/unresolved-package-handler.
2. Create tag.
3. Wait some time and nothing happen on quay.

Expected behavior
A new tag release is created on quay after creating the tag.