Expected Behavior

Short/preview description of all the tasks appear on hub.

Actual Behavior

For a few tasks, description is not showing up at hub.

Steps to Reproduce the Problem

1. open https://hub-preview.tekton.dev/
2. search or locate tasks viz [kn, curl, aws cli, buildkit]
3. you dont see any description unless you click on the task to find it.

Additional Info

• Noticed that tasks with full description separated by a single line are not affected.

• Currently the resources are differentiated on the basis of kind which are task/pipeline, hence to match the kubernetes kind, type needs to be renamed as kind

Currently the deployment of Hub to production is a manual process and is error prone since the image are built locally and the deployment is performed manually. 

Lets enable deployment of API service when a git (annotated) tag is created and pushed. 

/kind misc

When using 2 views of version in resource's view doesnot work as expected as one overrides the other.

Version{
   view("default")  
   view("tiny")
}  

Resource{
  Attribute("latestVersion", Version, "Latest version of resource", func() {
  Attribute("versions", ArrayOf(Version), " Version of resource")

  view("default", func() {
      Attribute("latestVersion", func() {
			View("default")
      })
      Attribute("versions", func() {
			View("tiny")
      })
  })
}

When using default view for a response in an API, in default view both shows same view of Versions.
but latestVersion should show default and versions should show tiny.

The coverage tool doesn't handle very well when the go code is not on the root of the repository, so this was disabled on the hub (prow configuration). This issue is to not forget about it and track work on re-enabling it in the future.

/area test-infra

Feature request

When installing a Task or Pipeline, allow an installation script to be run so that dependent resources can be created alongside the Tekton resources.

Use case

In tektoncd/catalog#556 a Task author has provided a number of helpful installation scripts that can be used to setup a ConfigMap & credential Secrets that are needed for their Task to operate. The ConfigMap in particular is a long-lived piece of configuration that makes sense to include alongside the main installation of the Task. However, at the moment, I'm not sure there's a good way to get from browsing the Hub to this installation script to set up the ConfigMap.

So the idea would be to run an installation script as part of installing Tasks from the Hub interface. Maybe the installation script could itself be a Task for the Hub to run?

# hypothetical task/orka-full/0.1/hub-install.yaml
kind: Task
apiVersion: tekton.dev/v1beta1
metadata:
  name: install-orka-full-catalog-task
spec:
  params:
  - name: namespace
    default: "default"
  - name: api-endpoint
    default: "http://10.221.188.100"
  image: bitnami/kubectl
  script: |
    cat > configmap.yaml << 'EOF'
    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: orka-tekton-config
    stringData:
      ORKA_API: $(params.api-endpoint)
    EOF
    kubectl apply -n $(params.namespace) -f ./configmap.yaml

From this the Hub could generate a UI for the params, asking the user to enter the required information or accept the defaults. Then Hub could run the Task in the cluster, installing the dependent resources.

Edit to add: Maybe the Task's catalog directory could be mounted into its hub-install Task as a Workspace so that the scripts are accessible?

Endpoint: /resource/<resourceId>/versions
Get all versions of a resource using resource id

version { 
  id
  version
  rawUrl
  webUrl
}

API Response:

{
    "latest" : version,
      versions: [ ]version
}

Feature request

It would be nice to start setting up nightly builds for the Hub UI and API

Use case

With nightly builds in place:

• we could install to dogfooding from a nightly builds
• we would have the machinery in place when the time comes to make a first release

The CI job should test the migration and check if the schema is applied properly

API: "/categories"
Get all categories with their associated tags sorted by name.

Endpoint- /
It would return the status as "Ok" when server is started successfully.

Discussed briefly in the working group today, but it would be great to have some plans around things we want to highlight when we are ready to announce an official launch/milestone for the catalog + hub.

Some things we might want to do:

• Record a demo
• Do a podcast (e.g. CDF)
• Create an interactive tutorial at https://tekton.dev/try/

Theme: "what can i do now that i couldn't do before”

Ideally we could highlight other Tekton projects as well, e.g. an end to end experience with the hub, catalog + CLI

For inspiration: the helm charts announcement

Expected Behavior

The error should be printed on the console.
eg. If the API service doesn't find GH_CLIENT_ID then error should be printed
that env var is not set.

Actual Behavior

Pod fails to run but doesn't print the error that env var is not set.

Adds an Endpoint /auth/login which will authenticate a user using GitHub OAuth,
add the user in DB, and returns a jwt which would be needed to access rating APIs.

The current swagger and openapi-v3 autogenerated files fail validation when checked against https://apitools.dev/swagger-parser/online/ .
Lets ensure that these files are valid to allow easier integration of API (server) with external tools

/kind bug

Expected Behavior

• Check if the gen folder us updated properly in CI

Actual Behavior

• Currently CI just builds and test the api, the CI also needs to check if the gen folder is updated properly

Feature request

Please add an option for a permanent url for tasks, rather than the current brittle links.

Use case

As a contributor to the Cloud Native Buildpacks project, I would like to link to the buildpacks task in hub (https://hub-preview.tekton.dev/detail/16, github link) in our documentation. Unfortunately, the current nature of the link is very brittle, given that it's merely indexed by position, and can easily be mutated if another task is added in prior to our task.

Please add an option for a permanent url, so we can safely and reliably point users to the hub site.

Feature request

Create a tool that will check periodically to make sure https://hub-preview.tekton.dev/ is up and will ping slack if it isn't.

One option is to use https://github.com/bitnami-labs/kubewatch but that's not required.

I think it is reasonable for tekton build cop responsibilities to at least include making sure this tool is up; what is less clear is who will be responsible for following up if the hub itself is down (could be build cop, could be hub OWNERS).

(Following up on some discussion in the working group)

Use case

If https://hub-preview.tekton.dev/ was to go down, we want to be able to find out right away. As we figure out the processes around the hub and our SLOs, a great step along the way would be to at least notify folks when there is an outage.

Expected behaviour

• To showcase everything that is present in the repo of that particular resource

Actual behaviour

• Currently Hub showcases:

  • resource-name
  • displayName,
  • tags,
  • readme
  • yaml file

  for a paritucular resource

Query resources based on name, type of the resource.
Returns array of resources with their details and latest version.
It would work like a fuzzy search where the exact name of resources need not be necessary.
Endpoint:

/query?name=<>&type=<>&limit=<>

name - The name of the resource
type - eg. task, pipeline
limit - the number of resources to be returned. default value = 100

examples:
/query?name=build&type=task

• It would return all the tasks which have build in their name.
  eg. build-image, buildah.

/query?name=build
- It would return all type of resource which have build in their name.

/query?name=pipelines&limit=25
- It would return resources with type pipelines.
The number of resources would be 25.

All resources returned should be sorted by rating and then by name.

Endpoint: PUT /resource/<id>/rating
id - ID of a resource
Use JWT of user in header Authorization to validate user for the API.

Use existing goa plugin for zap logger instead of creating a new one
plugin

Expected Behavior

date-time fields (updatedAt,...) should respect RFC3339 section 5.6 (see https://swagger.io/docs/specification/data-models/data-types/) or ISO 8601

Actual Behavior

Date is not formatted correctly

Steps to Reproduce the Problem

1. curl http://api.hub.tekton.dev/query?name=buildah&kinds=task&limit=100&match=exact
2. look at the updatedAt fields

Additional Info

• UI Screenshots(if applicable)

  (Add ui screenshots here)
  

find resources using type, name and returns array of resource details
with the latest version.
Endpoint: /resource/{type}/{name}
type - eg. task, pipeline
name - name of resource eg.buildah, argocd

Add tektoncd/hub to the prow project (to enable auto-merge, commands, …) and setup a basic CI.

Endpoint: GET /resource/<id>/rating
id - ID of a resource
Use JWT of user in header Authorization to validate user for the API.

Lets add a skeleton for a the api server for Hub.

API to create an agent user with required scopes.
Endpoint: PUT /system/users/agent
Body:

name: "<name of agent>"
scopes: "<scopes required for agent>"

Pass JWT of User in Header as Authorization.
Users must have agent:create scope to create an agent.
Return a JWT of the agent.

Use Case:
For cronjob to call API to refresh a catalog after a certain interval.
the agent will have catalog:refresh scope.

When testing out https://hub-preview.tekton.dev/ I noticed if I scroll down the page and select a card, it does not scroll back to the top of the window and thus sorta just shows no content. I wondered if it was a loading issue but it turns out my scroll position was just kept between the two pages.

Endpoint: POST /system/config/refresh
User JWT must have config:refresh scope to invoke this API.
returns config checksum.

When installing a task using tkn hub minimum pipeline version should be checked with the pipelines version installed in the cluster.
If it is incompatible, the user should be warned

API would return all resources with their details and latest version sorted by rating and then by name.

Endpoint:

/resources?limit=<>

Limit - Returns the number of resources on the limit

Fetch resource using resourceID.

Endpoint- /resource/{resourceID}
It would return information about a particular resource.

Based on the https://github.com/tektoncd/community/blob/master/teps/0003-tekton-catalog-organization.md#deprecation--removal-strategy, task or any other resources can be deprecated in the catalog

There will be annotation tekton.dev/deprecated: "true" for deprecated resource

Hub should this information in the UI

Database migration should have rollback if in the case of running the migrations it fails, then all the changes should be rollbacked.

Expected Behavior

• DB should have the backup of users logged in Hub

Actual Behavior

• Currently, whenever we have a new release we blow away the db which results in the loss of data

Add a header to the current deployment - http://ui-tekton-hub.apps.openshift-web.p0s5.p1.openshiftapps.com/ to display a "Beta or Experimental" header/ribbon.

In the current tekton hub preview (https://ui-tekton-hub.apps.openshift-web.p0s5.p1.openshiftapps.com/) (which looks AMAZING btw :D) all of the tasks we currently have in the catalog defualt to "official" support tier:

Since we haven't yet put in place the level of testing we want to for the official and verified support tiers (tektoncd/catalog#373) let's default everything to "community" for now, and we can evaluate and update Tasks as we go and promote to official and verified.

Some after tasks after being opened are giving 500: Internal Server Error while some are not.

Below is the screenshot for gcs-delete-bucket task which is giving the error. Link to the task here

Task which is not showing the error Link is here

As documented in tektoncd/cli#605, it would be nice if the hub cli followed a similar approach for referring to Tekton resources in docs/user facing messages. To address this for hub, I believe all that would need to happen is to update the usage for commands:

Capitalize pipeline/task under Available commands for hub get -h:

Get resource manifest by its name, kind, catalog, and version

Usage:
tkn hub get [flags]
  tkn hub get [command]

Available Commands:
  pipeline    Get Pipeline by name, catalog and version
  task        Get Task by name, catalog and version

Flags:
      --from string      Name of Catalog to which resource belongs to. (default "tekton")
  -h, --help             help for get
      --version string   Version of Resource

Global Flags:
      --api-server string   Hub API Server URL (default "https://api.hub.tekton.dev")

Use "tkn hub get [command] --help" for more information about a command.

Capitalize pipeline/task under Available commands for hub get task -h and hub get pipeline -h for description/examples:

Task

Get Task by name, catalog and version

Usage:
tkn hub get task [flags]

Examples:
  
Get a Task of name 'foo':

    tkn hub get task foo

or

Get a Task of name 'foo' of version '0.3':

    tkn hub get task foo --version 0.3


Flags:
  -h, --help   help for task

Global Flags:
      --api-server string   Hub API Server URL (default "https://api.hub.tekton.dev")
      --from string         Name of Catalog to which resource belongs to. (default "tekton")
      --version string      Version of Resource

Pipeline

Get Pipeline by name, catalog and version

Usage:
tkn hub get pipeline [flags]

Examples:
  
Get a Pipeline of name 'foo':

    tkn hub get pipeline foo

or

Get a Pipeline of name 'foo' of version '0.3':

    tkn hub get pipeline foo --version 0.3


Flags:
  -h, --help   help for pipeline

Global Flags:
      --api-server string   Hub API Server URL (default "https://api.hub.tekton.dev")
      --from string         Name of Catalog to which resource belongs to. (default "tekton")
      --version string      Version of Resource

/kind cleanup

Feature request

Enable the Open Graph protocol, or a similar set of meta information for unfurling purposes, on task pages, so that links reflect the individual task, rather than the Hub information. This will make shared links more understandable.

Use case

When I share links to the Buildpacks task on platforms like Slack/Twitter/LinkedIn/WhatsApp, I'd like to have the preview of the link be a preview of my task, as opposed to the Tekton Hub site.

For example, this is what happened when I tried slacking a link:

Similarly, when I tried sending the link through WhatsApp, I saw:

Previews of the link could make the links more understandable.

Hub source should follow the Tekton source convention and add Copyright headers.

Search a resource that matches kind, name & version from the input.
returns resource details with that particular version.
Endpoint: /resource/{kind}/{name}/{version}
kind - eg. task, pipeline
name - name of resource eg.buildah, argocd
version - eg. 0.1, 1.1

Example:
/resource/task/buildah/0.4

• search for 0.4 version of buildah task and returns if available

Feature request

In #82 we are creating a tool to at least notify us if the hub is down, but what is less clear is what it means when it is down and how urgent it is to fix it. For example, is it so important it be up that we want folks to be on call outside of working hours?

We discussed this a bit in the hub working group and in the productivity working group, and one interesting point is that as long as the hub isn't actually hosting Tasks/Pipelines (and it isn't - just referring ppl to git, and probably eventually to an OCI registry) then the hub going down won't actually break anyone; it just makes it harder to discover Tasks.

Proposal initial SLA: we will make sure the hub is up during build cop working hours, which will vary depending on who is build cop, and will only be Monday-Friday and not include holidays.

However, a counterpoint: if folks try to visit the hub and it is down, this might give them a negative impression of the project?

Use case

As a user of Tekton, I try to visit the hub on the weekend, and find that it is down. Is it acceptable for me to wait until Monday for it to be up?

fetch resource using versionID.

Endpoint- /resource/version/{versionID}
It would return resource details with that particular version.

Enable CI to test pull requests

Enable CI to test pull requests for UI as well