-
Notifications
You must be signed in to change notification settings - Fork 55
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
Added support for builder-jammy-full
, and made it default
#2659
Conversation
Note: rails and wordpress require updates to work ... rails simply goes 404. wordpress in apps, cli-apps does not stage:
|
7b851e1
to
667777d
Compare
Codecov ReportAttention:
... and 18 files with indirect coverage changes 📢 Thoughts on this report? Let us know!. |
note: dropped hard-coded user/group information. note: staging scripts to use based on chosen builder image (glob matching, details in reference docs) chore: switched to builder-jammy-full as default builder. note: The old bionic based builder is still supported, via a custom set of staging scripts. chore: updated testsuite (wordpress, rails require bionic builder for now) chore: extended action tracing in server and scripts chore: factored assembly of stage env into separate function to avoid `funlen` warning on `newJobRun`.
162b6f3
to
cbb6b76
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.
It looks good to me! Pretty nice. I would just make a couple of small refactoring:
since the staging script ConfigMap contains a bit of information it will be probably easier to handle it as a small struct. It a bit error prone to use the Data["xxx"]
because you could get some errors with just a typo, and also you have to know/remember the type that you are getting to cast it properly (such the uid/guid).
So I would create something like this with a constructor:
type StagingScriptConfig struct {
UserID int
GroupID int
Base string
DownloadImage string
UnpackImage string
Builder string
BuilderImage string
}
func NewStagingScriptConfig(config *v1.ConfigMap) (*StagingScriptConfig, error) {
stagingScript := &StagingScriptConfig{
Base: config.Data["base"],
// ...
}
groupID, err := strconv.ParseInt(config.Data["groupID"], 10, 64)
if err != nil {
return nil, err
}
stagingScript.GroupID = int(groupID)
// ...
return stagingScript, nil
}
and as a personal preference I would also move out the fallback check.
It will do one more loop in case of a missing match, but it's much more readable (and it should be just a rare case). Also performance-wise I don't think it makes any difference.
stagingScripts := []*StagingScriptConfig{}
for _, configmap := range configmapList.Items {
stagingScript, err := NewStagingScriptConfig(configMap)
if err != nil {
return nil, err
}
stagingScripts = append(stagingScripts, stagingScript)
// check for matching staging script
matched, err := filepath.Match(pattern, stagingScript.Builder)
if err != nil {
return nil, err
}
if matched {
logger.Info("locate staging scripts - match", "name", configmap.Name, "for", pattern, "builder", builder)
return stagingScript, nil
}
}
// no matches, find fallback
for _, stagingScript := range stagingScripts {
if stagingScript.Builder == "*" || stagingScript.Builder == "" {
logger.Info("locate staging scripts - using fallback", "name", fallback.Name)
return stagingScript, nil
}
}
return nil, fmt.Errorf("no matches, no fallback")
That small comment needs quite a bit of code work ... Still, most of it is ok and will work on that. The search logic of yours however is semantically different. |
…lly. this simplified the resolution of `base` references too. search kept as-is
Comment addressed with commit fb2c9b0. |
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.
Just a small comment.
more tracing (full set of specs, explicit note about base/inheritance)
Checked in:
Check 1
|
builder-jammy-full
builder-jammy-full
, and made it default
ticket #2153
chart epinio/helm-charts#502
docs epinio/docs#356