-
Notifications
You must be signed in to change notification settings - Fork 131
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
Introduce selective triggers #1001
Conversation
Name any `json:"name,omitempty" yaml:"name,omitempty"` | ||
} | ||
|
||
func (pushItem PushGitEventTriggerItem) toString() string { |
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.
nit: why not Stringer.String()
? https://pkg.go.dev/fmt#Stringer
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.
Because these toString
functions are helper functions for finding duplicated items, the Enabled property is omitted when comparing two items.
Co-authored-by: Olivér Falvai <[email protected]>
Checklist
README.md
is updated with the changes (if needed)Version
Requires a MINOR version update
Context
This PR introduced bitrise.yml data model changes to support selective build triggering (per workflow and pipeline build triggers).
Changes
WorkflowModel
andPipelineModel
got a newTriggers
propertyTriggers
property is a structure with (for now) tree fields, that reflect the matching git event type:PushTriggers
,PullRequestTriggers
, andTagTriggers
PushTriggers
,PullRequestTriggers
, andTagTriggers
are lists of the related trigger itemstype
,workflow
, andpipeline
fields are not needed anymore and event type related parts are removed from the filter field names:push_branch
→branch
commit_message
changed_files
enabled
pull_request_source_branch
→source_branch
pull_request_target_branch
→target_branch
pull_request_label
→label
draft_pull_request_enabled
→draft_enabled
pull_request_comment
→comment
commit_message
changed_files
enabled
tag
→name
enabled
Since the new triggers follow a slightly different structure than the original trigger map, the new
Triggers
model is manually parsed by implementing theyaml.Unmarshaler
interface, to be able to warn users about misconfiguration.E.g.: if you simply move an existing trigger map under a workflow's triggers, with the default yaml parsing
bitrise validate
would give this error message:with the custom parsing, this is the error message: