-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Add prebuildDefaultBranchOnly
setting – EXP-574
#18716
Conversation
prebuildDefaultBranchOnly
setting – EXP-574
2645ab6
to
e5c8e3a
Compare
cb6c888
to
f08fbf5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Woohoo! Thanks, @AlexTugarev. 🌮
Left a first round of comments about the design changes here. Feedback is welcome!
01f1ec4
to
ad8298e
Compare
ad8298e
to
b9df6aa
Compare
@@ -74,6 +82,20 @@ export namespace Project { | |||
return project.settings.enablePrebuilds; | |||
} | |||
|
|||
export function getPrebuildBranchStrategy(project: Project): ProjectSettings.PrebuildBranchStrategy { | |||
if (typeof project.settings?.enablePrebuilds === "undefined") { | |||
return "defaultBranch"; // default value for `settings.prebuildDefaultBranchOnly` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TODO: clarify if the change of the default behavior for pre-existing projects is acceptable. This would disable prebuilds on branches other than the default one once deployed. We might need a nudge in-app, so this change is not causing trouble.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can return allBranches
here to mimic the current behavior for pre-existing projects and postpone this decision/change to a later point in time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to change this as mentioned before, i.e. if prebuild settings aren't persisted use allBranches
as default strategy.
85219af
to
cd5e720
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
UI code looks pretty good to me. I think we could improve it by adjusting how we handle updating project settings so it's using a mutation and updating optimistically.
> | ||
<option value="defaultBranch">Default branch (e.g. main)</option> | ||
<option value="allBranches">All branches</option> | ||
{/* <option value="selectedBranches">Matched by pattern</option> */} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can this be removed?
cd5e720
to
d53d9eb
Compare
* Wether prebuilds (if enabled) should only be started on the default branch. | ||
* Defaults to `true` on project creation. | ||
*/ | ||
prebuildDefaultBranchOnly?: boolean; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
here (similar to enablePrebuilds above) we introduce an optional property where undefined
means true
. I think that is confusing. Can we make it prebuildAllBranches?: boolean
or as we are going to allow a pattern already use a pattern internally and make it *
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alternatively, introduce a non-boolean property (i.e. the strategy thing below).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to remove the optional from prebuildAllBranches
. This was a concern of rolling out to Gitpod Cloud.
Once we agree on a data migration path, we can remove the ?
.
I'm also OK with using constant to represent those states, e.g. all-branches
, default-branch
, matched-branches
. Actually this would be even simpler, as we are using a <select>
in frontend, which maps to a tuple of boolean to represents this state.
@@ -0,0 +1,199 @@ | |||
/** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for writing a test ❤️
) { | ||
const prebuildPrecondition = this.prebuildManager.checkPrebuildPrecondition({ config, project, context }); | ||
|
||
const shouldRun = Project.hasPrebuildSettings(project) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why is this check not part of checkPrebuildPrecondition
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see you use this to check if we need to call appRules. We could move them to checkPrebuildCondition
as well as they seem to also only use the passed-in state (config).
OTOH I understood we would simple deprecate and remove the appRules config. Why don'T we do that already?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As we are to remove appRules, which are also marked as deprecated here, I wanted to make it easier to remove those parts. This means, the new check has to be complete if appRules
are removed. But this also means, for pre-existing projects appRules should continue working. Once the data migration is done, this code paths are no longer used and we can remove it easily.
/** | ||
* | ||
* @deprecated | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to move this logic to checkPrebuildPrecondition
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
basically same as #18716 (comment)
W.r.t. #18716 (comment) We're going to create a follow-up with an aligned shape and structure of prebuild settings which would also include a lazy data migration for existing projects. There is agreement to not hold up this change, as we the internally discussed changes would be applicable in the follow-up as well. |
/unhold |
Description
This adds a new setting to allow limit prebuilds to run on the default branch only. It will be enabled by default for new projects when prebuilds get enabled. For existing projects this won't have any limiting effect.
Summary generated by Copilot
🤖 Generated by Copilot at 2645ab6
This pull request adds a new setting to control whether prebuilds are triggered only for the default branch of a project. This setting is part of the experimental public API and can be configured per project. The setting is added to the protobuf definition, the Go and TypeScript types, the API response, and the project creation logic. The default value is
true
.Related Issue(s)
Fixes EXP-574
How to test
prebuild-manager.spec.ts
https://at-defaultb846df8cc3.preview.gitpod-dev.com/projects/<YOURPROJECT>/events
, e.g.Documentation
Preview status
Gitpod was successfully deployed to your preview environment.
Build Options
Build
Run the build with werft instead of GHA
Run Leeway with
--dont-test
Publish
Installer
Add desired feature flags to the end of the line above, space separated
Preview Environment / Integration Tests
If enabled this will build
install/preview
If enabled this will create the environment on GCE infra
Valid options are
all
,workspace
,webapp
,ide
,jetbrains
,vscode
,ssh
. If enabled,with-preview
andwith-large-vm
will be enabled./hold