feat: Add support for uninitialized custom params #1898
Conversation
aThorp96
force-pushed
the
main
branch
2 times, most recently
from
63c9279 to
25e1f90
Compare
|
You probably (is actually highly recommended since it checks for secret leaks and things like that) want to install pre-commit and do a It would save a bit of the planet too by not having wasted CPU cycles :D |
|
/assign @chmouel |
|
(prow-commands failes cause it need a rebase with latest change) |
There was a problem hiding this comment.
I think you can easily add a e2e for this here https://github.com/openshift-pipelines/pipelines-as-code/blob/main/test/gitea_params_test.go#L250-L250
| ret[value.Name] = value.Value | ||
| } else if value.SecretRef != nil { | ||
|
|
||
| _, paramIsStd := stdParams[value.Name] |
There was a problem hiding this comment.
should we check that the key in stdParams and parsedFromComment actually exist in there? (i am surprise golangci-lint didn't bug you about this)
There was a problem hiding this comment.
That's what we're doing here, actually. At this point in the code we don't care about the value, just if the param exists in the stdParams and parsedFromCOmment maps, so we're checking the ok return-value instead of the map's value at that key.
When a Custom Param is defined without any value, it may still be templated-in to the pipeline when a value is provided via a gitops comment
Changes
Add support for defining Custom Params in the Repository without any value, allowing the value to be supplied by the webhook. Add a new optional field
requiredto the Custom Param, which enforces that the value is supplied via the webhook if not specified in the Repository.If a Custom Param is defined without any value, no value is supplied in the payload, and it is not marked as
required, then the param is omitted and the behaviour has no change from the current state. To this extent the feature is backwards compatible.Documentation is not included yet in chase semantic changes are requested.
Submitter Checklist
📝 Ensure your commit message is clear and informative. Refer to the How to write a git commit message guide. Include the commit message in the PR body rather than linking to an external site (e.g., Jira ticket).
♽ Run make test lint before submitting a PR to avoid unnecessary CI processing. Consider installing pre-commit and running pre-commit install in the repository root for an efficient workflow.
✨ We use linters to maintain clean and consistent code. Run make lint before submitting a PR. Some linters offer a --fix mode, executable with make fix-linters (ensure markdownlint and golangci-lint are installed).
📖 Document any user-facing features or changes in behavior.
🧪 While 100% coverage isn't required, we encourage unit tests for code changes where possible.
🎁 If feasible, add an end-to-end test. See README for details.
🔎 Address any CI test flakiness before merging, or provide a valid reason to bypass it (e.g., token rate limitations).
If adding a provider feature, fill in the following details:
(update the documentation accordingly)