Skip to content

[prebuild] Support opening a specfic prebuild #13706

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

Closed
wants to merge 1 commit into from
Closed

Conversation

csweichel
Copy link
Contributor

@csweichel csweichel commented Oct 10, 2022

Description

This PR enables users to open a specific prebuildm, and integrates this capability on the dashboard.

How to test

  1. Make sure there's a prebuild and a newer commit on the same branch
  2. Go the prebuild view
  3. Open the specific prebuild and observe it's the correct state

Release Notes

[prebuild] Add support for opening specific prebuilds

Documentation

Werft options:

  • /werft with-local-preview
    If enabled this will build install/preview
  • /werft with-preview
  • /werft with-integration-tests=all
    Valid options are all, workspace, webapp, ide

@werft-gitpod-dev-com
Copy link

started the job as gitpod-build-cw-open-prebuild.3 because the annotations in the pull request description changed
(with .werft/ from main)

@csweichel
Copy link
Contributor Author

csweichel commented Oct 10, 2022

/werft run

👍 started the job as gitpod-build-cw-open-prebuild.5
(with .werft/ from main)

@werft-gitpod-dev-com
Copy link

started the job as gitpod-build-cw-open-prebuild.6 because the annotations in the pull request description changed
(with .werft/ from main)

@csweichel
Copy link
Contributor Author

csweichel commented Oct 10, 2022

/werft run

👍 started the job as gitpod-build-cw-open-prebuild.7
(with .werft/ from main)

@injectable()
export class OpenPrebuildPrefixContextParser implements IPrefixContextParser {
@inject(Config) protected readonly config: Config;
static PREFIX = /^\/?open-prebuild\/([^\/]*)\//;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow, many thanks @csweichel for implementing a new context URL prefix for this!

However, I'm curious why a new prefix is more beneficial than "just" pointing a Prebuild view's "New Workspace" button to the (already-supported) fully-qualified commit context URL -- if you open the exact commit that was used to create the prebuild, you're guaranteed to get this prebuild, right? 💭

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you open the exact commit that was used to create the prebuild, you're guaranteed to get this prebuild, right?

Aye. Two reasons not to build it this way:

  1. I did not see a clean way to construct the commit context URL for all SCM provider
  2. It relies on the behaviour that we do actually open the prebuild for that commit given the correct context URL. Given the reliability of this feature I wanted to make this rock solid and identify the prebuild directly.

Another question would be: why use a prefix context parser rather than a regular context parser. This also has a couple of reasons:

  • regular context parser are tied to the SCM system, i.e. assume they're part of the SCM inversify container. A PrebuildContextParser would break this assumption.
  • permission checks can only happen in the server - if we wanted this to be a context parser, we'd need to make the permission checks part of that flow. Using a prefix context parser we can just rely on the permission checks already present in the SCM context parsing flow. This is an indicator to me that the current authorisation model has deficits we need to fix.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Makes sense. (I guess to achieve the commit context URL trick, we'd need to always store the commit's treeURL in our metadata. But I'm happy to go with your approach that identifies prebuilds directly. 👍)

@jankeromnes
Copy link
Contributor

jankeromnes commented Oct 11, 2022

Note: I'll give this PR a quick rebase, in the hopes of getting it to build. 🤞

@jankeromnes
Copy link
Contributor

jankeromnes commented Oct 11, 2022

Insert coin to try again 🎰

/werft run

👍 started the job as gitpod-build-cw-open-prebuild.9
(with .werft/ from main)

@jankeromnes
Copy link
Contributor

jankeromnes commented Oct 11, 2022

And again

/werft run

👍 started the job as gitpod-build-cw-open-prebuild.10
(with .werft/ from main)

@csweichel
Copy link
Contributor Author

csweichel commented Oct 11, 2022

@jankeromnes this might need a clean slate 🍽️ 😄

@jankeromnes
Copy link
Contributor

jankeromnes commented Oct 11, 2022

Indeed:

/werft run with-clean-slate-deployment

👍 started the job as gitpod-build-cw-open-prebuild.11
(with .werft/ from main)

@jankeromnes
Copy link
Contributor

jankeromnes commented Oct 11, 2022

I guess that luck is permanently stuck. Maybe let's move this work to a different branch. Happy to do this now. 🚚

href={gitpodHostUrl.withContext(`${prebuild?.info.changeUrl}`).toString()}
href={gitpodHostUrl
.withContext(`open-prebuild/${prebuild?.info.id}/${prebuild?.info.changeUrl}`)
.toString()}
>
<button>New Workspace ({prebuild?.info.branch})</button>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess the (branch) part of the button label no longer makes sense when we're opening the prebuild.

Maybe let's remove it?

Suggested change
<button>New Workspace ({prebuild?.info.branch})</button>
<button>New Workspace</button>

Or clarify it?

Suggested change
<button>New Workspace ({prebuild?.info.branch})</button>
<button>New Workspace With This Prebuild</button>

@jankeromnes
Copy link
Contributor

jankeromnes commented Oct 11, 2022

Okay, I've tested this (over in #13768), but it doesn't see to do what I expected:

  1. Added a repository as a new Project
  2. Created a branch with a new "commit A" (and waited for the prebuild to be finished successfully)
  3. Added a second "commit B" on top, in the same branch (also waited for successful prebuild)
  4. When I navigate to "Prebuilds", I see two successful commits on my branch 👍
  5. However, whichever I choose to open, I also seem to get the latest prebuild (with "commit B")

But, clicking on "New Workspace" in the prebuild of "commit A" should give me a workspace based on "commit A", right?

@csweichel
Copy link
Contributor Author

Let's move the conversation over to #13768. Will pick it up from there.

@csweichel csweichel closed this Oct 13, 2022
@jankeromnes jankeromnes deleted the cw/open-prebuild branch December 8, 2022 16:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants