profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/abayer/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

abayer/bigtop 2

Mirror of Apache Bigtop

abayer/buildnumber-maven-plugin 2

This plugin is designed to give you a build number. So when you might make 100 builds of version 1.0-SNAPSHOT, you can differentiate between them all.

abayer/artifactory-plugin 1

Jenkins artifactory plugin

abayer/avro-maven-plugin 1

Maven 2 Plugin for processing Apache Avro files. Avro is a subproject of Apache Hadoop.

abayer/backend-extension-indexer 1

Generate the list of extension points and their known implementations

abayer/acceptance-test-harness 0

Attempted port from selenium-tests to Java

Pull request review commenttektoncd/pipeline

Turn on most of golangci-lint's `exclude-use-default` rules, address problems

 func (source *ClusterTask) ConvertTo(ctx context.Context, sink apis.Convertible) }  // ConvertFrom implements api.Convertible+// nolint:revive

and done.

abayer

comment created time in 2 days

PullRequestReviewEvent

push eventabayer/tektoncd-pipeline

Andrew Bayer

commit sha 24bca00a9a653e719327e4df5645b405d37632c0

Turn on most of golangci-lint's `exclude-use-default` rules, address problems This started with me wanting to make sure every exported element had a proper comment, but then I just decided to set `exclude-use-defaults` to `false`, which enables a bunch of rules (see https://golangci-lint.run/usage/configuration/) that are nice-to-haves that often result in a giant pile of failures in existing code. So I "fixed" all those failures as well. I then decided that some of the `exclude-use-defaults` checks weren't actually relevant, and switched to explicitly including the relevant excluded rules (you can find the full list via `golangci-lint run --help`) that actually made sense, skipping the ones around things like not checking returns of `f.Close()`, using variables in opening files etc, and using permissions other than `0x00` ones. Finally, I added the `unconvert` linter to check for cases where we do things like `string(alreadyAStringVar)`, just 'cos why not. Signed-off-by: Andrew Bayer <andrew.bayer@gmail.com>

view details

push time in 2 days

Pull request review commenttektoncd/pipeline

Turn on most of golangci-lint's `exclude-use-default` rules, address problems

 func (source *ClusterTask) ConvertTo(ctx context.Context, sink apis.Convertible) }  // ConvertFrom implements api.Convertible+// nolint:revive

Yeah, I think I'll make that change - it'll be less confusing.

abayer

comment created time in 2 days

PullRequestReviewEvent

pull request commenttektoncd/pipeline

Turn on most of golangci-lint's `exclude-use-default` rules, address problems

@imjasonh I trimmed down the include (and also fixed it to be include, 'cos it was includes, which is wrong - oy!) list in .golangci.yml to just be the two revive rules that require there be a comment on every exported element and that said comment be properly formatted, and added a comment explaining that to .golangci.yml.

abayer

comment created time in 2 days

push eventabayer/tektoncd-pipeline

Andrew Bayer

commit sha aa8b8f2eb4c6c9920cb18e79fcf015ce27588da0

Turn on most of golangci-lint's `exclude-use-default` rules, address problems This started with me wanting to make sure every exported element had a proper comment, but then I just decided to set `exclude-use-defaults` to `false`, which enables a bunch of rules (see https://golangci-lint.run/usage/configuration/) that are nice-to-haves that often result in a giant pile of failures in existing code. So I "fixed" all those failures as well. I then decided that some of the `exclude-use-defaults` checks weren't actually relevant, and switched to explicitly including the relevant excluded rules (you can find the full list via `golangci-lint run --help`) that actually made sense, skipping the ones around things like not checking returns of `f.Close()`, using variables in opening files etc, and using permissions other than `0x00` ones. Finally, I added the `unconvert` linter to check for cases where we do things like `string(alreadyAStringVar)`, just 'cos why not. Signed-off-by: Andrew Bayer <andrew.bayer@gmail.com>

view details

push time in 2 days

Pull request review commenttektoncd/pipeline

Turn on most of golangci-lint's `exclude-use-default` rules, address problems

 type Pipeline struct { type PipelineStatus struct { } +// PipelineMetadata returns the Pipeline's ObjectMeta, implementing PipelineObject

...ok, I started doing this and then my head began to ache from how many of these there are. I'll try to find a linting rule we can enable to require this and, if I can, I'll enable it and fix every offending comment in a follow-up.

abayer

comment created time in 2 days

PullRequestReviewEvent

Pull request review commenttektoncd/pipeline

Turn on most of golangci-lint's `exclude-use-default` rules, address problems

 func (source *ClusterTask) ConvertTo(ctx context.Context, sink apis.Convertible) }  // ConvertFrom implements api.Convertible+// nolint:revive

Maybe I should have just unified receiver names in these cases...

abayer

comment created time in 2 days

PullRequestReviewEvent

Pull request review commenttektoncd/pipeline

Turn on most of golangci-lint's `exclude-use-default` rules, address problems

 func (source *ClusterTask) ConvertTo(ctx context.Context, sink apis.Convertible) }  // ConvertFrom implements api.Convertible+// nolint:revive

To disable the receiver-naming: receiver name sink should be consistent with previous receiver name source for ... check. What I did here was get rid of // nolint:revive applying to the whole file and just had it apply to specific functions.

abayer

comment created time in 2 days

Pull request review commenttektoncd/pipeline

Turn on most of golangci-lint's `exclude-use-default` rules, address problems

 type Pipeline struct { type PipelineStatus struct { } +// PipelineMetadata returns the Pipeline's ObjectMeta, implementing PipelineObject

👍

abayer

comment created time in 2 days

PullRequestReviewEvent

Pull request review commenttektoncd/pipeline

Turn on most of golangci-lint's `exclude-use-default` rules, address problems

 issues:     - gosec   max-issues-per-linter: 0   max-same-issues: 0+  # Off-by-default rules to enable, primarily around comments+  includes:+  - EXC0002

Yup yup!

abayer

comment created time in 2 days

PullRequestReviewEvent

Pull request review commenttektoncd/pipeline

pkg/pod: extracting function from the package…

 func (b *Builder) Build(ctx context.Context, taskRun *v1beta1.TaskRun, taskSpec  	// Convert any steps with Script to command+args. 	// If any are found, append an init container to initialize scripts.+	// TODO(vdemeester) get one list of steps, return 1 list of containers

Do you mean passing in one list of both steps and sidecars, and getting back one list of both step containers and sidecar containers?

vdemeester

comment created time in 2 days

Pull request review commenttektoncd/pipeline

pkg/pod: extracting function from the package…

 func (b *Builder) Build(ctx context.Context, taskRun *v1beta1.TaskRun, taskSpec  	// Convert any steps with Script to command+args. 	// If any are found, append an init container to initialize scripts.+	// TODO(vdemeester) get one list of steps, return 1 list of containers+	// TODO(vdemeester) extract breakpoint from scripts

What's the reason to do this? (just trying to understand, since, honestly, last time I was in this code, breakpoints weren't a thing yet!)

vdemeester

comment created time in 2 days

Pull request review commenttektoncd/pipeline

pkg/pod: extracting function from the package…

 func (b *Builder) Build(ctx context.Context, taskRun *v1beta1.TaskRun, taskSpec 		return nil, err 	} -	// Rewrite steps with entrypoint binary. Append the entrypoint init+	// Rewrite steps with entrypoint binàary. Append the entrypoint init

Surprise accent! =)

vdemeester

comment created time in 2 days

Pull request review commenttektoncd/pipeline

pkg/pod: extracting function from the package…

 import (  	"github.com/tektoncd/pipeline/pkg/apis/pipeline" 	"github.com/tektoncd/pipeline/pkg/apis/pipeline/v1beta1"+	"github.com/tektoncd/pipeline/pkg/pod/script" 	"gomodules.xyz/jsonpatch/v2" 	corev1 "k8s.io/api/core/v1"-	k8serrors "k8s.io/apimachinery/pkg/api/errors" 	metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" 	"k8s.io/apimachinery/pkg/types" 	"k8s.io/client-go/kubernetes" )  const (-	binVolumeName    = "tekton-internal-bin"-	binDir           = "/tekton/bin"+	binVolumeName    = "tekton-internal-bin" // FIXME(vdemeester) remove duplication with script package

There comes a time in every project when a pkg/util/const.go ends up being handy. =)

vdemeester

comment created time in 2 days

PullRequestReviewEvent
PullRequestReviewEvent

pull request commenttektoncd/pipeline

Turn on most of golangci-lint's `exclude-use-default` rules, address problems

Thanks for the suggestions, @jerop!

abayer

comment created time in 2 days

push eventabayer/tektoncd-pipeline

koneko096

commit sha 5dcd43431fe1fdc62a4ed59fde3f01ca43536d72

Fix structure and enable tic autogenerate TOC should be called using `mdtoc --inline` command. Inline mode requires toc tag to be there.

view details

pritidesai

commit sha 0a19aa3cb44626a0695a0a604644c9da2ee9d4e1

updating release cheat sheet Add a new item as part of the release creation process, creating a branch in the GitHub repo for the release that was just created. This branch can be useful to the website https://tekton.dev/docs/ to point to the latest release. Also, the released branch is needed for creating a patch. Instead of creating such branch just before creating a patch, make it part of the release process. Fixing the typo while renaming the context to dogfooding instead of dogfoodin (typo)

view details

Jason Hall

commit sha eac6817e7fa3ff6e142e3694c4253dc1b91267ea

Fix link to API compatibility policy

view details

Andrew Bayer

commit sha 62aa24165d5536d8519fbd0f8990289ea782b34c

Turn on most of golangci-lint's `exclude-use-default` rules, address problems This started with me wanting to make sure every exported element had a proper comment, but then I just decided to set `exclude-use-defaults` to `false`, which enables a bunch of rules (see https://golangci-lint.run/usage/configuration/) that are nice-to-haves that often result in a giant pile of failures in existing code. So I "fixed" all those failures as well. I then decided that some of the `exclude-use-defaults` checks weren't actually relevant, and switched to explicitly including the relevant excluded rules (you can find the full list via `golangci-lint run --help`) that actually made sense, skipping the ones around things like not checking returns of `f.Close()`, using variables in opening files etc, and using permissions other than `0x00` ones. Finally, I added the `unconvert` linter to check for cases where we do things like `string(alreadyAStringVar)`, just 'cos why not. Signed-off-by: Andrew Bayer <andrew.bayer@gmail.com>

view details

push time in 2 days

Pull request review commenttektoncd/pipeline

Turn on most of golangci-lint's `exclude-use-default` rules, address problems

 func (pt PipelineTask) validateTask(ctx context.Context) (errs *apis.FieldError) 	return errs } +// TaskSpecMetadata returns the metadata of the PipelineTask's EmbeddedTask spec. func (pt *PipelineTask) TaskSpecMetadata() PipelineTaskMetadata { 	return pt.TaskSpec.Metadata } +// HashKey is used as the key for this PipelineTask in the DAG

Yeah, makes sense. Doing so now.

abayer

comment created time in 2 days

PullRequestReviewEvent

push eventabayer/tektoncd-pipeline

pritidesai

commit sha 41192338e661b9dc7bceb845255221db89b5e082

Promoting onError to beta Pipeline 0.27 was released in August 2021 which introduced an alpha feature to specify onError in a step. This feature was implemented in the PR #4106: https://github.com/tektoncd/pipeline/pull/4106 To enable this feature, the Tekton Pipeline deployment had to set enable-api-fields to alpha. After discussing this in the API WG: https://docs.google.com/document/d/17PodAxG8hV351fBhSu7Y_OIPhGTVgj6OJ2lPphYYRpU/edit#heading=h.ig94pf1w10xc We have sent an email out to collect the feedback from the users. @skaegi is looking forward to this promotion. This commit is updating task validation to no longer require enable-api-fields is set to alpha. The documentation is updated to moved it out of the alpha section. The example yamls moved out of alpha. Updated e2e to not include alpha flag.

view details

pritidesai

commit sha e31e4c3973f5f8d8574b3f430b96762c6fd7a5b7

links to the patch release v0.28.2 Adding the links to the latest patch release v0.28.2.

view details

Jerop

commit sha 918ca4fafde37674feb92e435b60f239aeb29eb1

Add reference to `Task` authoring recommendations We have `Task` authoring recommendations in the [Tekton Catalog][recommendations]. As described in https://github.com/tektoncd/pipeline/issues/3948, users need these recommendations but they are not easily discoverable. Therefore, adding a reference to these recommendations in `Tasks` documentation to make it more discoverable. Closes https://github.com/tektoncd/pipeline/issues/3948 [recommendations]: https://github.com/tektoncd/catalog/blob/main/recommendations.md

view details

Andrew Bayer

commit sha 2e5dcbd38d60549b4ca654d553ff7d1e6087da74

Turn on most of golangci-lint's `exclude-use-default` rules, address problems This started with me wanting to make sure every exported element had a proper comment, but then I just decided to set `exclude-use-defaults` to `false`, which enables a bunch of rules (see https://golangci-lint.run/usage/configuration/) that are nice-to-haves that often result in a giant pile of failures in existing code. So I "fixed" all those failures as well. I then decided that some of the `exclude-use-defaults` checks weren't actually relevant, and switched to explicitly including the relevant excluded rules (you can find the full list via `golangci-lint run --help`) that actually made sense, skipping the ones around things like not checking returns of `f.Close()`, using variables in opening files etc, and using permissions other than `0x00` ones. Finally, I added the `unconvert` linter to check for cases where we do things like `string(alreadyAStringVar)`, just 'cos why not. Signed-off-by: Andrew Bayer <andrew.bayer@gmail.com>

view details

push time in 3 days