or
or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up
Syntax | Example | Reference | |
---|---|---|---|
# Header | Header | 基本排版 | |
- Unordered List |
|
||
1. Ordered List |
|
||
- [ ] Todo List |
|
||
> Blockquote | Blockquote |
||
**Bold font** | Bold font | ||
*Italics font* | Italics font | ||
~~Strikethrough~~ | |||
19^th^ | 19th | ||
H~2~O | H2O | ||
++Inserted text++ | Inserted text | ||
==Marked text== | Marked text | ||
[link text](https:// "title") | Link | ||
![image alt](https:// "title") | Image | ||
`Code` | Code |
在筆記中貼入程式碼 | |
```javascript var i = 0; ``` |
|
||
:smile: | Emoji list | ||
{%youtube youtube_id %} | Externals | ||
$L^aT_eX$ | LaTeX | ||
:::info This is a alert area. ::: |
This is a alert area. |
On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?
Please give us some advice and help us improve HackMD.
Syncing
xxxxxxxxxx
Shipwright Beta API Workshop
Full build strategy with all possible fields
NOTE: DO NOT EDIT before workshop unless something is missing.
Full build with all possible fields
NOTE: DO NOT EDIT before workshop unless something is missing.
Full buildrun with all possible fields
NOTE: DO NOT EDIT before workshop unless something is missing.
API conventions
name
fields in arrays to the furthest extent possible. UtilizepatchMergeKey=name
andpatchStrategy=merge,retainKeys
annotations to enablekubectl patch
on arrays.List of proposed change requests:
Example: Title
Scope: API Convention|BuildStrategy|Build|BuildRun
Originator: Put in your name
What: Put in your proposal. Note: this is about changing our API objects to become nicer and consistent. It is NOT about introducing features.
Migration: assess if the old version can be migrated to the new version and vice versa without any loss of information
Add convention about lists different elements - ACCEPTED
Scope: API Convention
Originator: Sascha
What: Today, we are inconsistent in that. Basically it is about all arrays that we have which contain definitions of different kinds. I suggest that we:
name
field. This is also helpful forkubectl patch
I think to correlate items if we also specify the following on the array property:* do NOT have a kind or type field. Inherited pattern for volumes is the example; type is implicitly defined.Moved to separate proposal.Examples:
We follow this pattern today already for
spec.volumes
.We should imo do this for
spec.sources
, see belowWe should imo do this for
spec.triggers
= removespec.trigger.when[].type
Migration: no problem in both directions because type is redundant information.
Add convention regarding 3rd party service credentials - ACCEPTED
Scope: API Convention
Originator: Adam Kaplan
What: We currently use a
credentials
object to reference a secret that used for authentication and authorization with 3rd party services. This proposes replacing the object reference with a simple field. Each field indicates the reason why the secret is provided.git clone example:
image push example:
Concern - using
<reason>Secret
will result in false positives from code scanners.<reason>SecretName
may result in fewer false positives. This was tested and not confirmed.Rename buildSteps to steps - ACCEPTED
Scope: BuildStrategy
Originator: Sascha
What: I think that
steps
is shorter but still descriptive enough. For consistency we can then rename the underlying Go type fromBuildStep
toStep
Migration: no problem in both directions
Remove inline Container in BuildStep - ACCEPTED
Scope: BuildStrategy
Originator: Sascha
What: change
BuildStep
to not anymore have an inlineContainer
object, but instead put in only those fields that we copy into the TaskRun. Those today arename
,image
,imagePullPolicy
,workingDir
,command
,args
,env
,resources
,securityContext
, andvolumeMounts
. It will then look like this:Migration: Possible in both directions. When migrating from alpha to beta we potentially throw away other fields that could theoretically be defined such as
EnvFrom
orLivenessProbe
, but given we never forwarded those to the TaskRun anyway, we do not loose anything. In the future, we can revisit if we should forward additional fields that would make sense such as for exampleLifecycle
.Notes: We should try and keep our API independent of dependencies (k8s, Tekton), unless we are comfortable fully supporting a given dependent field.
Examples - not exposing the
script
field in Tekton steps, limitingEnvFrom
.Move build-run-deletion annotation to spec.retention - ACCEPTED
Scope: Build
Originator: Sascha
What: introduce
.spec.retention.atBuildDeletion
of typebool
with defaultfalse
Migration: no problem in both directions
Suggestion - change default behavior to set the owner reference on BuildRuns, use
retention
field to opt out of this behavior.Interim is
spec.retention.keepOrphaned
. Community can continue to brainstorm names for this field.Build sources - DECLINED in favor of "Revert sources"
Scope: Build
Originator: Sascha
What: Remove source, go forward with sources, and move contextDir to
.spec.strategy
(or.spec
?):Migration: there will only be problems if somebody defines a Build with a Git and a Bundle source, or with more than one of them. This cannot be handled. But we will need to discuss whether this is at all allowed anyway.
Revert sources, only have
spec.source
- ACCEPTEDScope: Build
Originator: Adam Kaplan
What: A counter-proposal to "Build Sources" - we should only support a single source per build/buildRun, but allow multiple types within
source
.git example:
local example:
bundle (container image) example. Rename to "ociArtifact":
Migration: Git and bundleContainer source builds will be able to migrate, perhaps with some re-mapping of YAML keys.
Local source builds will switch to using
spec.source.local
instead ofspec.sources[0].localCopy
.HTTP sources would be dropped as a feature and no longer supported.
Builds with
spec.sources
andspec.source
will not be able to migrate. Question - how common is this?Suggestions:
contextDir
to be top level (under "source")status.source
, where relevant information is populated. Example:status.source.git.sha
,status.source.ociArtifact.digest
Eliminate dockerfile field - ACCEPTED
Scope: Build
Originator: Sascha
What: Remove
.spec.dockerfile
Migration: we will add a dockerfile parameter to all sample build strategies for Dockerfile-based builds. We can also continue to set the unofficial
$(params.DOCKERFILE)
for some time until we remove it to not break old build strategies. The rest is doable.Note - some concerns regarding parameter and migration.
Eliminate builder field - ACCEPTED
Scope: Build
Originator: Sascha
What: Remove
.spec.builder
Migration: we will modify the s2i sample build strategies and add a parameter for the image name a volume for the secret. But I do not see how we can support a good migration path here especially in the build strategy.
Eliminate volume description on Build - ACCEPTED
Scope: Build
Originator: Sascha
What: remove
.spec.volumes[].description
. This brings it in synchronization with parameters where the description is only provided in the strategy and cannot be overwritten.Migration: not possible because of removal
Remove
status from Build and BuildStrategy/ClusterBuildStrategy - ACCEPTEDregistered
Scope: Build
Originator: Adam Kaplan
What: Remove
status
from objects which do not result in executing code -Build
,BuildStrategy
, andClusterBuildStrategy
.Migration: No direct API migration. Clients which report this information should drop these fields.
Notes:
TODO: Deprecate
status
in alpha API?Rename latestTaskRunRef to taskRunName - ACCEPTED
Scope: BuildRun
Originator: Sascha
What: rename
.status.latestTaskRunRef
to.status.taskRunName
Migration: no problem in both directions
Notes:
Name
in the suffix? Otherwise.status.taskRun
would be viable.Results of the detect-secrets investigation will inform this decision.
Remove generated service account from API - ACCEPTED
Scope: BuildRun
Originator: Adam Kaplan
What: Remove API-level support for generating a service account. Instead, use a string reference to a service account in a BuildRun, and eventually the Build object as well. Allow the ".generated" service account value, which continues the existing behavior until it is deprecated/removed.
Migration: serviceAccount.generated = true can move to
serviceAccount = .generated
.Notes:
Consolidate buildRef and buildSpec - ACCEPTED
Scope: BuildRun
Originator: Sascha
What: move the referenced (
.spec.buildRef.name
) or inline build specification (.spec.buildSpec
) into one top-level. One can then specify eitheror
This makes it behave consistent with
spec.strategy
on the Build.Migration: no problem in both directions
Drop Kind/Type fields - DECLINED
Scope: API Convention
Originator: Sascha
What: do NOT have a kind or type field. Inherited pattern for volumes is the example; type is implicitly defined.
Use Kind/Type fields as type discriminators - ACCEPTED
Scope: API Convention
Originator: Adam Kaplan
What: Use "type discriminators" if an API object has some form of implied polymorphism. For example, source types or volume sources.
Counter-proposal to "Drop Kind/Type fields"
Problem: volumeSource is not maintained by us so we would have a problem to provide a type field - we could introduce our own volumeSource with selected options only.
Proposal: only introduce type field when we own the options (for source and triggers but not for volume sources) -> we go that path