Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using parent devfile, only want one project checked out - Is it possible? #23196

Closed
isuftin opened this issue Oct 15, 2024 · 4 comments
Closed
Assignees
Labels
area/devfile-spec Issues related to Devfile v2 area/devworkspace-operator kind/question Questions that haven't been identified as being feature requests or bugs. status/analyzing An issue has been proposed and it is currently being analyzed for effort and implementation approach

Comments

@isuftin
Copy link

isuftin commented Oct 15, 2024

Summary

We are trying to provide a sample workspace dashboard for our users. We want to have a workspace for the sample dashboard items with certain projects checked out using the development branch. We also want to use a parent devfile which defines a container component, a project and 1..n commands. In the child project we want to override the container component, add commands as well as specify a different project to check out.

The goal here is to give users enough of a head start so they can easily copy the devfile into their projects and change what they need.

Everything works great except in the resulting workspace, we have two projects checked out with the same code from two different branches.

Parent devfile:

---
schemaVersion: 2.3.0
metadata:
  generateName: universal-dev
  description: |
    Devfile for configuring a Universal Developer Image environment for
    development.

components:
  - name: udi
    container:
      image: our.internal.docker.registry/universal-developer-image:3.16

projects:
  - name: starter-workspace
    git:
      remotes:
        origin: "https://our.internal.gitlab.repo/applications/openshift/dev-files/starter-workspace.git"
      checkoutFrom:
        revision: development

commands:
  - id: some-command
    exec:
      commandLine: "do-a-thing --update"
      component: udi
      label: This does a thing

Child devfile:

---
schemaVersion: 2.3.0
metadata:
  generateName: aws-dev
  description: |
    Devfile for working within AWS

parent:
  # This refers to the above parent devfile in its own repo
  uri: https://our.internal.gitlab.repo/applications/openshift/dev-files/starter-workspace/-/raw/main/devfile.yaml?ref_type=heads
  components:
    - name: udi
      container:
        image: our.internal.docker.registry/aws-developer-image:1
  projects:
    - name: starter-workspace
      git:
        remotes:
          origin: "https://our.internal.gitlab.repo/applications/openshift/dev-files/aws-developer-workspace.git"

commands:
  - id: whoami
    exec:
      commandLine: "whoami"
      component: udi
      label: do a whoami

So what we end up with here is two projects checked out. starter-workspace checked out and on the development branch (good) and then also aws-developer-workspace checked out to the main branch (bad). This is probably happening because by default, if a devfile doesn't specify a project, DevSpaces will check out the project/branch that includes the devfile the workspace was created from.

If we also define projects in the child devfile and name it aws-developer-workspace but specify the development branch, DevSpaces opens a workspace with two projects, both checked out to the development branch of the aws-developer-workspace project. The names are starter-workspace and aws-developer-workspace Great, but we really only want one project checked out in the workspace.

I've also tried setting the projects parameter in the parent to an empty array with no luck.

I wonder if there's actually a way to achieve what we're going for?

This is being done on RH OpenShift DevSpaces 3.16.1 using the DevWorkspace Operator 0.31.0

Relevant information

No response

@isuftin isuftin added the kind/question Questions that haven't been identified as being feature requests or bugs. label Oct 15, 2024
@che-bot che-bot added the status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. label Oct 15, 2024
@dmytro-ndp dmytro-ndp added area/devfile-spec Issues related to Devfile v2 area/devworkspace-operator and removed status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. labels Oct 16, 2024
@ibuziuk
Copy link
Member

ibuziuk commented Oct 17, 2024

@isuftin could you please try replacing the projects with starterProjects in the parent devfile?

@ibuziuk ibuziuk added the status/analyzing An issue has been proposed and it is currently being analyzed for effort and implementation approach label Oct 17, 2024
@ibuziuk ibuziuk self-assigned this Oct 17, 2024
@ibuziuk ibuziuk moved this to Unplanned Tasks in Eclipse Che Team A Backlog Oct 17, 2024
@isuftin
Copy link
Author

isuftin commented Oct 17, 2024

@ibuziuk - Unfortunately, an issue we're seeing with OpenShift DevSpaces is when we use starterProjects instead of projects, the parent's project under starterProjects does not get checked out (good, I guess) but also none of the commands from the parent get inherited in the flattened devfile and they don't appear in the Terminal -> Tasks -> Devfile menu. It's an issue we're working through with RedHat but this also means that at least for the time being we're stuck using projects in the parent.

@ibuziuk
Copy link
Member

ibuziuk commented Oct 17, 2024

@isuftin For Dev Spaces I would recommend opening JIRA for Red Hat https://issues.redhat.com/browse/
Eclipse Che tracker is used for upstream issues only.

But, to answer the question "Using parent devfile, only want one project checked out - Is it possible?".
Have you considered having a parent without projects at all e.g. smth like https://registry.devfile.io/viewer/devfiles/community/udi ? after that you can do smth. like this in child - https://github.com/che-incubator/quarkus-api-example/pull/40/files

NOTE: it is not needed to specify projects / starter-projects in general as long as devfile is part of the repository (which is the recommended aproach)

@isuftin
Copy link
Author

isuftin commented Oct 17, 2024

@ibuziuk - We do have a ticket open w/ RedHat and are poking around for a solution. I figured I'd ask here first.

But, to answer the question "Using parent devfile, only want one project checked out - Is it possible?".
Have you considered having a parent without projects at all e.g. smth like https://registry.devfile.io/viewer/devfiles/community/udi ? after that you can do smth. like this in child - https://github.com/che-incubator/quarkus-api-example/pull/40/files

That's what we ended up doing. But because these devfiles are meant to be 'starter' workspaces, I was hoping I could get the projects that are checked out by default to be checked out from the development branch. But because the workspace starts from the dashboard sample grid link, the dashboard sample points to devfiles in the main branch of the associated projects. Furthermore, we were hoping that developers, when they use the devfile as an example in their own projects, they could have just overridden the projects portion in their own devfile.

So right now we have these workspaces opened up with the project checked out from the main branch.

Not a big deal but was hoping there was a good solution to this.

Thanks for the back and forth!

@isuftin isuftin closed this as completed Oct 17, 2024
@ibuziuk ibuziuk moved this from Unplanned Tasks to ✅ Done in Eclipse Che Team A Backlog Oct 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/devfile-spec Issues related to Devfile v2 area/devworkspace-operator kind/question Questions that haven't been identified as being feature requests or bugs. status/analyzing An issue has been proposed and it is currently being analyzed for effort and implementation approach
Projects
Status: ✅ Done
Development

No branches or pull requests

4 participants