text:
Migrate/Upgrade previous version with a default timeout…

Changes
In case of a controller upgrade, we may still store previous versions
of resource that may not have been the default set. This migrates
those "in memory" to make sure we do not panic in those cases.
This also gives a great example of how to use a mutating webhook to
migrate some resources from one version to another.
Should close #1075 , but I still need to dig into why a new deployment would not set defaults correctly.
/priority critical-urgent
/cc @bobcatfish
Signed-off-by: Vincent Demeester vdemeest@redhat.com
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:

[x] Includes tests (if functionality changed/added)
[ ] Includes docs (if user facing)
[x] Commit messages follow commit message best practices

See the contribution guide for more details.
Double check this list of stuff that's easy to miss:

If you are adding a new binary/image to the cmd dir, please update
the release Task and TaskRun to build and release this image

Release Notes
Fix controller panicking on missing Timeout on TaskRun (existing or new)

/hold

This also gives a great example of how to use a mutating webhook to migrate some resources from one version to another.

I tried to google this but didnt see an obvious answer: I thought there was a difference between a "mutating" webhook and a non-mutating webhook, i.e. something you need to declare when actually creating the webhook controller itself? Up until this point I thought we were only validating, not mutating, so I am surprised we can just start suddenly mutating. I think I'm missing some knowledge on how this actually works tho, any help appreciated! :bow_panda:
Is it because of:
https://github.com/tektoncd/pipeline/blob/0ee3b1491aa5b38d48b4547eeb4c87d11852b3a3/config/200-clusterrole.yaml#L15-L17
And if so, does that mean we've been mutating all this time? (I didn't think we were 🤔)

I have two thoughts:

We should also probably update https://github.com/tektoncd/pipeline/blob/2c9bbc54409f757da8b7f87e343420b8b7306320/pkg/reconciler/v1alpha1/taskrun/taskrun.go#L536 to check for nil
I'm a bit confused about why the defaulting that we added before wasn't getting applied anymore (I'm guessing b/c before we were only applying it via the webhook, and in this case, the TaskRuns already exist in etcd?) - I'd like to revisit defaulting in general and our story around values that can be nil (but that's probably a story for our postmortem!)

But I'm happy to go ahead and get this in to fix 0.5.1! Thanks for fixing this so fast and for putting up with my many comments @vdemeester  🙇♀
/lgtm
/approve
/meow space

@vdemeester do we want to take the approach of defaulting values via a mutating webhook in all cases like this in the future?

I think we do, yes

It looks to me like the root cause is:
https://github.com/tektoncd/pipeline/blob/2c9bbc54409f757da8b7f87e343420b8b7306320/pkg/reconciler/v1alpha1/taskrun/taskrun.go#L536
So another way to approach this would be to check if tr.Spec.Timeout is nil before trying to use Duration?

Right, that would another way to fix it. The only thing I didn't want is to add yet another place where we check / add defaults. Might be the simplest fix though :angel:

Right, that would another way to fix it. The only thing I didn't want is to add yet another place where we check / add defaults. Might be the simplest fix though 👼

I feel like we should do that also, b/c as it is we have code that if called as-is could panic 😓  (e.g. in a unit test). It's a separation of concerns for sure - I guess the ideal case would be ensuring via the way these objects are instantiated that all the fields have valid values so every single function accessing them doesn't have to worry about them.

@bobcatfish #1085 for the simplest fix (to be cherry-picked), I'll update this one to have this mechanism to all resources :angel: :wink:

@bobcatfish Updated for pipelinerun too (and only that for now).

Updated :angel:

@vdemeester do we want to take the approach of defaulting values via a mutating webhook in all cases like this in the future?

I think the specific use case here is:

In release X, we add a new field with a default value
Objects created between X-1 and X do not have the field, but should have the default after release X

Is that accurate? If so, CRD conversion webhooks are the long-term solution here. Use of mutating webhook to perform this function is a stop-gap until we have those.

More information on CRD defaulting (alpha in 1.15): https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#defaulting

I think the specific use case here is:
* In release X, we add a new field with a default value

* Objects created between X-1 and X do not have the field, but should have the default after release X

Is that accurate? If so, CRD conversion webhooks are the long-term solution here. Use of mutating webhook to perform this function is a stop-gap until we have those.

@pmorie yes, that is accurate :hugs:

Cc @abayer @dibyom

/hold cancel

/lgtm

/test pull-tekton-pipeline-integration-tests

authors: abayer bobcatfish pmorie vdemeester


text:
Add workspace types for Task and TaskRun with validation

Changes
This allows users to use Volumes with Tasks such that:

The actual volumes to use (or subdirectories on those volumes) are
provided at runtime, not at Task authoring time
At Task authoring time you can declare that you expect a volume to
be provided and control what path that volume should end up at
Validation will be provided that the volumes (workspaces) are actually
provided at runtime

Before this change, there were two ways to use Volumes with Tasks:

VolumeMounts were explicitly declared at the level of a step
Volumes were declared in Tasks, meaning the Task author controlled the
name of the volume being used and it wasn't possible at runtime to use
a subdir of the volume
Or the Volume could be provided via the podTemplate, if the user
realized this was possible

None of this was validated and could cause unexpected and hard to
diagnose errors at runtime.
We have also limited (at least initially) the types of volume source
being supported instead of expanding to all volume sources, tho we can
expand it later if we want to and if users need it. This would reduce
the API surface that a Tekton compliant system would need to conform to
(once we actually define what conformance means!).
Part of #1438
In future commits we will add support for workspaces to Pipelines and
PipelineRuns as well; for now if a user tries to use a Pipeline with a
Task that requires a Workspace, it will fail at runtime because it is
not (yet) possible for the Pipeline and PipelineRun to provide
workspaces.
Future work:

Support for readonly
Support for configmap + secret volume types
Support in Pipeline + PipelineRun

Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:

[x] Includes tests (if functionality changed/added)
[x] Includes docs (if user facing)
[x] Commit messages follow commit message best practices

See the contribution guide for more details.
Double check this list of stuff that's easy to miss:

If you are adding a new binary/image to the cmd dir, please update
the release Task to build and release this image.

Reviewer Notes
If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.
Release Notes
Adds the concept of "workspaces" to Tasks. This allows Task authors to declare directories they expect to be provided via Volumes at runtime. At runtime, TaskRuns can provide PVCs or EmptyDirs to use for these directories.

Any reason to use StepTemplates for this ?

Basically just b/c it was convenient! :sweat_smile:  maybe one way to make this a bit cleaner would be to create a new "step template" just for this, merge it with the user provided step template, and pass the result into the pod creation function - not sure how much different that'd be tho :thinking:

This would mean the user has to use the variable substitution to get the name of the mountpoint right ? I think that's fair though :angel:

sgtm!

One question... is there a particular concern and reason why the WorkspaceBinding embeds a PVCSource / EmptyDir instead of just a volume name? I already have cases where I would really like to embed Secrets and ConfigMaps as volumes and this would be helpful. Is there some concern about supporting some kinds of volume types?
Also... could we consider adding a readOnly boolean on the WorkspaceBinding. I believe the implementation is to emit a VolumeMount which already supports this field.

One question... is there a particular concern and reason why the WorkspaceBinding embeds a PVCSource / EmptyDir instead of just a volume name? I already have cases where I would really like to embed Secrets and ConfigMaps as volumes and this would be helpful. Is there some concern about supporting some kinds of volume types?

Initially I thought "to be able to get the correct type of volume", but we don't really have to. So I'm now asking myself the same question :stuck_out_tongue_closed_eyes:

Also... could we consider adding a readOnly boolean on the WorkspaceBinding. I believe the implementation is to emit a VolumeMount which already supports this field.

:+1:

Here I've taken the example workspace taskrun yaml from this PR and added a volume to the podTemplate in the taskrun:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  resources:
    requests:
      storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
---
apiVersion: tekton.dev/v1alpha1
kind: TaskRun
metadata:
  generateName: custom-volume-
spec:
  workspaces:
    - name: custom
      volumeName: mypd
      subPath: my-subdir
    - name: custom2
      volumeName: mypd
  podTemplate:
    volumes:
      - name: mypd
        persistentVolumeClaim:
          claimName: my-pvc
  taskSpec:
    steps:
    - name: write
      image: ubuntu
      command: ["/bin/bash"]
      args: ["-c", "echo stuff > /workspace/custom/foo"]
    - name: read
      image: ubuntu
      command: ["/bin/bash"]
      args: ["-c", "cat /workspace/custom/foo | grep stuff"]
    - name: write2
      image: ubuntu
      command: ["/bin/bash"]
      args: ["-c", "echo stuffs > /workspace/custom2/foo"]
    - name: read2
      image: ubuntu
      command: ["/bin/bash"]
      args: ["-c", "cat /workspace/custom2/foo | grep stuffs"]
    workspaces:
    - name: custom
    - name: custom2

Is this about what you'd expect @skaegi , @vdemeester ?

In regards support for configmaps and secrets - we have plans to implement those as part of this (it's in the TODOs section at the top).
Is there any other reason to separate them out like this rather than just having the volume type embedded in the workspace definition?

Also - readOnly is definitely on the roadmap for workspaces! whether or not it's part of this PR.

(for a bit of context - @bobcatfish and I wrote it initially to use the podTemplate volumes but it felt like extra yaml when we could make it part of the binding spec and leave the podTemplate out of things completely)

Is this about what you'd expect @skaegi , @vdemeester ?

Oh, ok, I would maybe prefer the following (but :stuck_out_tongue:) to reduce a bit the verbosity of the thing.
# […]
spec:
  workspaces:
    - name: custom
      persistentVolumeClaim:
        claimName: my-pvc
      subPath: my-subdir
    - name: custom2
      persistentVolumeClaim:
        claimName: my-pvc
# […]

Thanks for the example @sbwsg -- that helps. I forgot that taskruns don't directly have volumes and agree the extra podSpec stuff just doesn't look great and does not enhance readability.

I went back through our current usage to verify and can confirm that if we had...
configMap [ConfigMapVolumeSource]
emptyDir [EmptyDirVolumeSource]
persistentVolumeClaim [PersistentVoluemClaimVolumeSource]
secret: [SecretVolumeSource]

all of our cases are covered.
We also on occasion might use downwardAPI volumes however that is always static and not parameterized. Especially in the context of a TaskRun I found downwardAPI a bit strange as it ends up looking up values against the Pod so I'm happy to not have it present in the WorkspaceBinding.
@bobcatfish a while back we had wondered about removing volumes from the Task. The TLDR; is I think we want to retain support. Looking through our usage I see cases where a Task wants to do work in emptyDir memory and also cases where we're mounting the hostPath. We might also directly generate non-parameterizable Tasks that hardcode the pvcs and devices involved so having volumes grants us flexibility there too.

This should be ready for a real review @skaegi @vdemeester @sbwsg ! 🎉

Oh and also https://github.com/tektoncd/pipeline/pull/1639/commits/e0a923752ba3404ad3e95d95b8a8aed30eac9b98 is just temporary while https://github.com/tektoncd/pipeline/pull/1702 is being reviewed, then i wont need that commit anymore :D

I think we might consider linking from the taskrun and task docs to the full example yaml.

kk! @sbwsg im adding links (maybe one day we can inline the examples!)

... @vdemeester should i be adding this to v1alpha2 instead?

... @vdemeester should i be adding this to v1alpha2 instead?
/hold
(on a related noted note we are gonna need to make sure we don't approve changes to v1alpha1 that should be in v1alpha2!)

Should be ready for another look @sbwsg @vdemeester @skaegi !

... @vdemeester should i be adding this to v1alpha2 instead?
/hold
(on a related noted note we are gonna need to make sure we don't approve changes to v1alpha1 that should be in v1alpha2!)

Good question. My feeling is that, it's a new field, won't break people and it is better to expose it as soon as possible (v1alpha2 is not exposed yet), so I am fine having this in v1alpha1 (we need to port it to v1alpha2, no big deal :angel: )

I1210 22:23:15.091] pkg/apis/pipeline/v1alpha1/git_resource.go:125:16: undefined: pipeline.WorkspaceDir
I1210 22:23:15.092] pkg/apis/pipeline/v1alpha1/pull_request_resource.go:142:15: undefined: pipeline.WorkspaceDir
I1210 22:23:15.092] pkg/apis/pipeline/v1alpha1/workspace_types.go:44:23: undefined: pipeline.WorkspaceDir

@bobcatfish Did you forget to commit something ? :thinking:

Thanks @vdemeester ! @skaegi you said you this approach looks like it'll work for you, @sbwsg mentioned you wanted to try this out a bit and give us some more feedback. Since we still have to do the Pipeline and PipelineRun portion of this, I'm assuming you'd be okay with merging this PR and continuing to iterate on the design as we keep working on it (let me know if not!)

I1216 14:37:17.611] pkg/workspace/apply_test.go:29: File is not `gofmt`-ed with `-s` (gofmt)
I1216 14:37:17.611] 			"custom": corev1.Volume{
I1216 14:37:17.611] pkg/pod/pod.go:34:2: `homeVolumeName` is unused (varcheck)
I1216 14:37:17.611] 	homeVolumeName      = "tekton-internal-home"
I1216 14:37:17.612] 	^
I1216 14:37:17.612] pkg/pod/pod.go:33:2: `workspaceVolumeName` is unused (varcheck)
I1216 14:37:17.612] 	workspaceVolumeName = "tekton-internal-workspace"
I1216 14:37:17.612] 	^

whoops

/lgtm

/hold cancel

/lgtm

source: gharchive/pull-request

authors: bobcatfish sbwsg skaegi vdemeester

repo: tektoncd/pipeline

license_type: permissive

license_source: bigquery


text:
[TEP-0142] Add ResolverRef to Ref

Changes
This commit is part of #7259. First step to support remote resoluton for StepAction. It adds ResolverRef to Ref, validation and conversion.
/kind featuree
Signed-off-by: Yongxuan Zhang yongxuanzhang@google.com

Submitter Checklist
As the author of this PR, please check off the items in this checklist:

[ ] Has Docs if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps
[x] Has Tests included if any functionality added or changed
[x] Follows the commit message standard
[x] Meets the Tekton contributor standards (including functionality, content, code)
[x] Has a kind label. You can add one by adding a comment on this PR that contains /kind <type>. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep
[ ] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of good release notes.
[ ] Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes
NONE

/kind feature

@Yongxuanzhang can you add docs for this in stepacitons.md under Referencing a StepAction?

/approve

@Yongxuanzhang can you add docs for this in stepacitons.md under Referencing a StepAction? Otherwise lgtm

Thanks! We can add docs when the feature is functional in the next/following PRs. Should be in very soon. 😄

@tektoncd/core-maintainers @tektoncd/core-collaborators please take a look 🙏🏾

Left some minor comments. Also, would you consider applying default resolver for StepAction @chitrangpatel @Yongxuanzhang ?
#6317 and https://github.com/tektoncd/community/blob/main/teps/0133-configure-default-resolver.md

Oh that's a good call. Let me take a look

Left some minor comments. Also, would you consider applying default resolver for StepAction @chitrangpatel @Yongxuanzhang ?
#6317 and https://github.com/tektoncd/community/blob/main/teps/0133-configure-default-resolver.md

Oh that's a good call. Let me take a look

Create an issue to track: https://github.com/tektoncd/pipeline/issues/7329
We can add it in a separate pr

@tektoncd/core-maintainers @tektoncd/core-collaborators please take a look 🙏🏾

/approve

authors: Yongxuanzhang chitrangpatel jerop


text:
Has anyone gotten typos.config to work on Neovim?

I'm trying to explicitly set the typos config using typos.config. However, it doesn't seem to get picked up. I've tried specifying the config value in all kinds of ways, but none of them seems to work:
require('lspconfig').typo_lsp.setup({
  init_options = {
    config = '/custom/path/.typos.toml',
    config = {'/custom/path/.typos.toml'},
  },
  config = {'/custom/path/.typos.toml'},
  config = '/custom/path/.typos.toml',
  settings = {
    typos = {
      config = {'/custom/path/.typos.toml'},
      config = '/custom/path/.typos.toml',
    }
  }
})

What am I doing wrong?

config is received via initializationOptions so it goes in init_options, eg:
require('lspconfig').typos_lsp.setup({
    init_options = {
      config = '/custom/path/.typos.toml',
    }
})

However, it looks like there's an edge case! When Neovim doesn't initialise typo_lsp with workspaceFolders  (ie: workspaceFolders = vim.NIL) the config file is ignored 😱 This is something that typos-lsp should handle, so I'll look into making a fix.
PS: It looks like workspaceFolders is derived from root_dir by default (ie: when not explicitly set). However, if workspaceFolders is not explicitly set, and root_dir is nil (because it doesn't contain any of these files) then we end up with rootPath = vim.NIL, rootUri = vim.NIL, workspaceFolders = vim.NIL and therefore an ignored config file 😞

Interesting, thanks for looking into it!

Hopefully this is now fixed in 0.1.12, let me know how it goes 🤞

@tekumara Is the v0.1.12 release supposed to show up under releases? It still seems to show v0.1.11 as the latest version 🤔

Unfortunately there's a 32-bit windows build error I haven't managed to fix yet blocking the release 😞

Fixed and v0.1.12 has been released, let me know how you go 🤞

@tekumara Yes, my issue has been fixed! Thank you very much!

source: gharchive/issue

authors: mawkler tekumara

repo: tekumara/typos-vscode

license: MIT

license_source: github-api


text:
Add option to specify telegram api server in app/build.gradle

Reference: https://core.telegram.org/bots/api#november-4-2020

This modification is not accepted, I will consider a better solution in a later version. Thank you very much for your PR.

repo: telegram-sms/telegram-sms


text:
Feature/story test/procedural test cases

Run yarn test mainnet to recreate testing
This PR creates a new procedural structure which creates a permutation of actions on each domain in a
storyDomain  {
  domainName: 'DAPP.LEND.AAVE',
  scenarios: [
    { domain: 'DAPP', actions: [Array] },
    { domain: 'DAPP', actions: [Array] }
  ]
}

created new procedural test structure using permutation of actions in a story domain
reimplemented test drivers to match these structure

@dumebi, can you write a description here of what i'm expected to test when switching branches?

hey @dumebi, can you write a description here of what we're expected to test when we switch to your feature/story_test branch?

just did @mkhoury93

yarn test mainnet doesn't work right away since new packages have been added. yarn install has to be executed prior


text:
Varios fixes for the new contracts

Updated the default config to not start with a remote db
Enabled admin endpoint for Prometheus to be able to delete old metrics
https://www.shellhacks.com/prometheus-delete-time-series-metrics/
Updated Manual data for USPCE
Added an example in the setup docs how to delete an instance
Added a global validation that all public addresses should start with 0x
and convert all to lower case to be consistent everywhere.
Removed the timeout/lastSubmit tracker as it causes a race condition -
check when the miner last submitted -> the tracker has the old value as
it hasn't updated yet -> the submitter submits although the 15threshold
hasn't passed yet.
Made all configs consistent starting with a capital letter.
Updated the contracts to the latest version.
Improved the logging in various places.
Last submit threshold wasn't working when the miner has never submitted
as it was returning 0 and the time diff calc didn't work.
Changed all hash vars to the new ones. timeOfLastNewValue ->
_TIME_OF_LAST_NEW_VALUE .. etc.
Fixed error handling for failed TX submits
Signed-off-by: Krasi Georgiev 8903888+krasi-georgiev@users.noreply.github.com

Pull Request Test Coverage Report for Build 584871394

37 of 114 (32.46%)  changed or added relevant lines in 11 files are covered.
5 unchanged lines in 2 files lost coverage.
Overall coverage increased (+0.4%) to 38.803%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pkg/tracker/tributeBalance.go
5
7
71.43%

pkg/tracker/currentVariables.go
0
3
0.0%

pkg/config/config.go
8
12
66.67%

pkg/db/proxy.go
12
16
75.0%

pkg/rpc/client.go
0
6
0.0%

pkg/rpc/contractRPC.go
0
9
0.0%

pkg/ops/miningManager.go
0
17
0.0%

pkg/pow/miningTasker.go
0
32
0.0%

Files with Coverage Reduction
New Missed Lines
%

pkg/ops/miningManager.go
1
0%

pkg/db/proxy.go
4
46.38%

Totals

Change from base Build 581310510:
0.4%

Covered Lines:
1511

Relevant Lines:
3894

💛  - Coveralls

authors: coveralls krasi-georgiev

repo: tellor-io/telliot


text:
Enhancement: Testnet, aspect ratio of Native Wallet Wombat seems wrong

Description
Wombat Logo is blurry
Reproduce
1: Click Connect
2: Select Native Wallet
Expected Behavior
Clear Logo of accepted Wallets

Environment Used
OS: OSX
Browser: Chrome

@DestinyDevTeam  this is what is coming back from the api for their icon, i've noticed it elsewhere as well.

Looks better now, I guess this is what we get from that image source.

authors: DestinyDevTeam DonaldPeat

repo: telosnetwork/teloscan


text:
🛑 QRCODE VIEWER is down

In f63ee84, QRCODE VIEWER (https://qrcode-viewer.onrender.com/qrcode-viewer/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: QRCODE VIEWER is back up in dced1ca after 41 minutes.

repo: templain/mywatcher


text:
chore(deps): bump

Applied mkpr on undefined
/tmp/mkpr.sh

:tada: This PR is included in version 2.0.126 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

repo: template-tools/template-sync-cli


text:
Unable to compile using v1.26.1

Expected Behavior
It to just work :)
Actual Behavior
After a go get -u ./... to update dependencies,
# go.temporal.io/sdk/internal/protocol
../../../../../go/pkg/mod/go.temporal.io/sdk@v1.25.1/internal/protocol/util.go:39:40: cannot use msg.Body (variable of type *anypb.Any) as *types.Any value in argument to types.AnyMessageName
# go.temporal.io/sdk/internal/common/metrics
../../../../../go/pkg/mod/go.temporal.io/sdk@v1.25.1/internal/common/metrics/grpc.go:120:44: cannot use s (variable of type *"github.com/gogo/status".Status) as *"google.golang.org/grpc/internal/status".Status value in argument to serviceerror.FromStatus

Steps to Reproduce the Problem
Apparently, updating from temporal SDK 1.26.0 to 1.26.1.  Minimal change:
% go get -u go.temporal.io/api <--- becomes 1.26.1

This also changes this dependency:
-       go.temporal.io/api v1.26.0 // indirect
+       go.temporal.io/api v1.26.1 // indirect
-       github.com/grpc-ecosystem/grpc-gateway v1.16.0 // indirect
+       github.com/grpc-ecosystem/grpc-gateway/v2 v2.18.1 // indirect

Details
go.mod:
require (
	github.com/Khan/genqlient v0.6.0
	github.com/aws/aws-sdk-go-v2 v1.23.4
	github.com/aws/aws-sdk-go-v2/config v1.25.10
	github.com/aws/aws-sdk-go-v2/feature/s3/manager v1.15.3
	github.com/aws/aws-sdk-go-v2/service/s3 v1.47.1
	github.com/aws/smithy-go v1.18.1
	github.com/google/go-containerregistry v0.17.0
	github.com/google/uuid v1.4.0
	github.com/oklog/ulid/v2 v2.1.0
	github.com/pborman/uuid v1.2.1
	github.com/redis/go-redis/v9 v9.3.0
	github.com/spf13/cobra v1.8.0
	github.com/spf13/viper v1.17.0
	go.temporal.io/sdk v1.25.1
)

require (
	github.com/agnivade/levenshtein v1.1.1 // indirect
	github.com/alexflint/go-arg v1.4.3 // indirect
	github.com/alexflint/go-scalar v1.2.0 // indirect
	github.com/aws/aws-sdk-go-v2/aws/protocol/eventstream v1.5.3 // indirect
	github.com/aws/aws-sdk-go-v2/credentials v1.16.8 // indirect
	github.com/aws/aws-sdk-go-v2/feature/ec2/imds v1.14.8 // indirect
	github.com/aws/aws-sdk-go-v2/internal/configsources v1.2.7 // indirect
	github.com/aws/aws-sdk-go-v2/internal/endpoints/v2 v2.5.7 // indirect
	github.com/aws/aws-sdk-go-v2/internal/ini v1.7.1 // indirect
	github.com/aws/aws-sdk-go-v2/internal/v4a v1.2.7 // indirect
	github.com/aws/aws-sdk-go-v2/service/internal/accept-encoding v1.10.3 // indirect
	github.com/aws/aws-sdk-go-v2/service/internal/checksum v1.2.7 // indirect
	github.com/aws/aws-sdk-go-v2/service/internal/presigned-url v1.10.7 // indirect
	github.com/aws/aws-sdk-go-v2/service/internal/s3shared v1.16.7 // indirect
	github.com/aws/aws-sdk-go-v2/service/sso v1.18.1 // indirect
	github.com/aws/aws-sdk-go-v2/service/ssooidc v1.21.1 // indirect
	github.com/aws/aws-sdk-go-v2/service/sts v1.26.1 // indirect
	github.com/cespare/xxhash/v2 v2.2.0 // indirect
	github.com/containerd/stargz-snapshotter/estargz v0.15.1 // indirect
	github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc // indirect
	github.com/dgryski/go-rendezvous v0.0.0-20200823014737-9f7001d12a5f // indirect
	github.com/docker/cli v24.0.7+incompatible // indirect
	github.com/docker/distribution v2.8.3+incompatible // indirect
	github.com/docker/docker v24.0.7+incompatible // indirect
	github.com/docker/docker-credential-helpers v0.8.0 // indirect
	github.com/facebookgo/clock v0.0.0-20150410010913-600d898af40a // indirect
	github.com/fsnotify/fsnotify v1.7.0 // indirect
	github.com/gogo/googleapis v1.4.1 // indirect
	github.com/gogo/protobuf v1.3.2 // indirect
	github.com/gogo/status v1.1.1 // indirect
	github.com/golang/mock v1.6.0 // indirect
	github.com/golang/protobuf v1.5.3 // indirect
	github.com/grpc-ecosystem/go-grpc-middleware v1.4.0 // indirect
	github.com/grpc-ecosystem/grpc-gateway/v2 v2.18.1 // indirect
	github.com/hashicorp/hcl v1.0.0 // indirect
	github.com/inconshreveable/mousetrap v1.1.0 // indirect
	github.com/jmespath/go-jmespath v0.4.0 // indirect
	github.com/klauspost/compress v1.17.3 // indirect
	github.com/magiconair/properties v1.8.7 // indirect
	github.com/mitchellh/go-homedir v1.1.0 // indirect
	github.com/mitchellh/mapstructure v1.5.0 // indirect
	github.com/opencontainers/go-digest v1.0.0 // indirect
	github.com/opencontainers/image-spec v1.1.0-rc5 // indirect
	github.com/pelletier/go-toml/v2 v2.1.0 // indirect
	github.com/pkg/errors v0.9.1 // indirect
	github.com/pmezard/go-difflib v1.0.1-0.20181226105442-5d4384ee4fb2 // indirect
	github.com/robfig/cron v1.2.0 // indirect
	github.com/sagikazarmark/locafero v0.4.0 // indirect
	github.com/sagikazarmark/slog-shim v0.1.0 // indirect
	github.com/sirupsen/logrus v1.9.3 // indirect
	github.com/sourcegraph/conc v0.3.0 // indirect
	github.com/spf13/afero v1.11.0 // indirect
	github.com/spf13/cast v1.6.0 // indirect
	github.com/spf13/pflag v1.0.5 // indirect
	github.com/stretchr/objx v0.5.1 // indirect
	github.com/stretchr/testify v1.8.4 // indirect
	github.com/subosito/gotenv v1.6.0 // indirect
	github.com/vbatts/tar-split v0.11.5 // indirect
	github.com/vektah/gqlparser/v2 v2.5.10 // indirect
	go.temporal.io/api v1.26.1 // indirect
	go.uber.org/atomic v1.11.0 // indirect
	go.uber.org/multierr v1.11.0 // indirect
	golang.org/x/exp v0.0.0-20231127185646-65229373498e // indirect
	golang.org/x/mod v0.14.0 // indirect
	golang.org/x/net v0.19.0 // indirect
	golang.org/x/sync v0.5.0 // indirect
	golang.org/x/sys v0.15.0 // indirect
	golang.org/x/text v0.14.0 // indirect
	golang.org/x/time v0.5.0 // indirect
	golang.org/x/tools v0.16.0 // indirect
	google.golang.org/genproto v0.0.0-20231127180814-3a041ad873d4 // indirect
	google.golang.org/genproto/googleapis/api v0.0.0-20231127180814-3a041ad873d4 // indirect
	google.golang.org/genproto/googleapis/rpc v0.0.0-20231127180814-3a041ad873d4 // indirect
	google.golang.org/grpc v1.59.0 // indirect
	google.golang.org/protobuf v1.31.0 // indirect
	gopkg.in/ini.v1 v1.67.0 // indirect
	gopkg.in/yaml.v2 v2.4.0 // indirect
	gopkg.in/yaml.v3 v3.0.1 // indirect
)

Specifications

Version: sdk 1.26.1
Platform: go 1.21

Due to work to deprecate gogoproto go.temporal.io/api v1.26.1  is not compatible with go.temporal.io/sdk v1.25.1. The SDK only is compatible with the version in its go.mod

go.temporal.io/api 1.26.1 has been retracted
https://github.com/temporalio/api-go/commit/b175d7eddedb89516a569ac6c5e2e837b02d0f9c

Problem

The SDK only is compatible with the version in its go.mod

⭐ For orgs using dependabot, this presents a problem based on the way that temporal is releasing their versions.
Reasoning being that we are running into compile issues from the following step of events:

Using go.temporal.io/sdk@v1.25.1
go.temporal.io/api@v1.27.0 released
Dependabot opens a PR for go.temporal.io/api@v1.27.0 released, without a dependabot PR for go.temporal.io/sdk@1.26.0-rc2 since it is a release candidate
Builds fail due to compile issues.

Proposal

The SDK only is compatible with the version in its go.mod

⭐ @Quinn-With-Two-Ns if that is true - should go.temporal.io/api@v1.27.0 been a pre-release / release-candidate?
A release candidate would ensure that dependabots would occur at the appropriate time to avoid incompatibility issues.
Thoughts?

should go.temporal.io/api@v1.27.0 been a pre-release / release-candidate?

No, The Go SDK is not the only consumer of go.temporal.io/api and their releases are not coupled in general.
I don't really see the problem with dependabot, the build failed as it should as you should not be updating the api by updating the go-sdk

authors: Quinn-With-Two-Ns chriscerk skandragon

repo: temporalio/sdk-go


text:
TestActivityRetryOnHBTimeout is flaky

Error from the build pipeline:
=== RUN   TestIntegrationSuite/TestActivityRetryOnHBTimeout

Handling connection for 7233

2021/09/23 07:46:13 INFO  Started Worker Namespace integration-test-namespace TaskQueue tq-5-TestIntegrationSuite/TestActivityRetryOnHBTimeout WorkerID 6171@fdbd4600-e1aa-46fb-6b79-777ba48942e4@

2021/09/23 07:46:13 DEBUG ExecuteActivity Namespace integration-test-namespace TaskQueue tq-5-TestIntegrationSuite/TestActivityRetryOnHBTimeout WorkerID 6171@fdbd4600-e1aa-46fb-6b79-777ba48942e4@ WorkflowType ActivityRetryOnHBTimeout WorkflowID test-activity-retry-on-hbtimeout RunID 362e659a-3ea4-4d68-9577-461d4230c1f7 Attempt 1 ActivityID 5 ActivityType HeartbeatAndSleep

2021/09/23 07:46:13 INFO  Running HeartbeatAndSleep activity Namespace integration-test-namespace TaskQueue tq-5-TestIntegrationSuite/TestActivityRetryOnHBTimeout WorkerID 6171@fdbd4600-e1aa-46fb-6b79-777ba48942e4@ ActivityID 5 ActivityType HeartbeatAndSleep Attempt 1 WorkflowType ActivityRetryOnHBTimeout WorkflowID test-activity-retry-on-hbtimeout RunID 362e659a-3ea4-4d68-9577-461d4230c1f7

2021/09/23 07:46:15 INFO  Task processing failed with error Namespace integration-test-namespace TaskQueue tq-5-TestIntegrationSuite/TestActivityRetryOnHBTimeout WorkerID 6171@fdbd4600-e1aa-46fb-6b79-777ba48942e4@ WorkerType ActivityWorker Error invalid activityID or activity already timed out or invoking workflow is completed

2021/09/23 07:46:16 INFO  Running HeartbeatAndSleep activity Namespace integration-test-namespace TaskQueue tq-5-TestIntegrationSuite/TestActivityRetryOnHBTimeout WorkerID 6171@fdbd4600-e1aa-46fb-6b79-777ba48942e4@ ActivityID 5 ActivityType HeartbeatAndSleep Attempt 2 WorkflowType ActivityRetryOnHBTimeout WorkflowID test-activity-retry-on-hbtimeout RunID 362e659a-3ea4-4d68-9577-461d4230c1f7

2021/09/23 07:46:18 INFO  Task processing failed with error Namespace integration-test-namespace TaskQueue tq-5-TestIntegrationSuite/TestActivityRetryOnHBTimeout WorkerID 6171@fdbd4600-e1aa-46fb-6b79-777ba48942e4@ WorkerType ActivityWorker Error invalid activityID or activity already timed out or invoking workflow is completed

2021/09/23 07:46:19 INFO  Running HeartbeatAndSleep activity Namespace integration-test-namespace TaskQueue tq-5-TestIntegrationSuite/TestActivityRetryOnHBTimeout WorkerID 6171@fdbd4600-e1aa-46fb-6b79-777ba48942e4@ ActivityID 5 ActivityType HeartbeatAndSleep Attempt 3 WorkflowType ActivityRetryOnHBTimeout WorkflowID test-activity-retry-on-hbtimeout RunID 362e659a-3ea4-4d68-9577-461d4230c1f7

    TestIntegrationSuite: integration_test.go:382:

        	Error Trace:	integration_test.go:382

        	Error:      	Received unexpected error:

        	            	workflow execution error (type: ActivityRetryOnHBTimeout, workflowID: test-activity-retry-on-hbtimeout, runID: 362e659a-3ea4-4d68-9577-461d4230c1f7): expected activity to fail but succeeded

        	Test:       	TestIntegrationSuite

2021/09/23 07:46:21 INFO  Stopped Worker Namespace integration-test-namespace TaskQueue tq-5-TestIntegrationSuite/TestActivityRetryOnHBTimeout WorkerID 6171@fdbd4600-e1aa-46fb-6b79-777ba48942e4@

    TestIntegrationSuite/TestActivityRetryOnHBTimeout: testing.go:916: test executed panic(nil) or runtime.Goexit: subtest may have called FailNow on a parent test

I think this was fixed (or at least improved) by #545

This test does not appear flaky anymore in CI

authors: cretz vitarb


text:
Update internal timers to use NewTimerWithOptions

What was changed

Change internal uses of NewTimer to NewTimerWithOptions
Created new AwaitWithTimeoutAndOption to allow specifying options for the underlying timer that's created

Why?

Because there's now a way to give a summary for internal timers, change internal code to use the new timer with summary command.
Checklist

Closes #1602

How was this tested:

Any docs updates needed?

@yuandrew - Looks like you can merge if/when CI passes (I kicked it again, looks like flaky test)

@cretz  looks like there's a regression with the TestWorkerVersioningTestSuite/TestCommitRules test, looking to repro this locally

authors: cretz yuandrew


text:
UI updates to WorkflowFilterSearch

Description & motivation 💭
Screenshots (if applicable) 📸

Before
After

Design Considerations 🎨
Testing 🧪
How was this tested 👻

[x] Manual testing
[ ] E2E tests added
[ ] Unit tests added

Steps for others to test: 🚶🏽♂🚶🏽♀

[ ] Verify all types of filters have the close button and it works/looks as expected
[ ] Verify Relative and Absolute Datetime filters work as expected
[ ] Verify Start/End time Datetime filter works as expected

Checklists
Draft Checklist
Merge Checklist
Issue(s) closed
DT-1359
Docs
Any docs updates needed?

Couple of thoughts

Were you going to fix the issue where clicking away from the Workflow Status filter doesn't reset it in the dropdown?
Should we also use this PR to remove the labs mode check from the new filters?

Were you going to fix the issue where clicking away from the Workflow Status filter doesn't reset it in the dropdown?

@rossedfort I have another task for this (DT-1360), but we also may be removing this filter entirely with the addition of Workflow counts.

Should we also use this PR to remove the labs mode check from the new filters?

I'll create a separate task for this and get it approved by product.

Looks like there is some slightly inconsistent behavior here. If the user has selected "relative" but not specified a duration, should we disable the "Apply" button?

I've disabled Apply if relative is selected and there is an error or no specified duration (https://github.com/temporalio/ui/pull/1613/commits/b0067201716becadc595e2ac9244932d8979e466).

Similarly, should we disable it if they select "absolute" and clear the date input?

The existing behavior for the datetime filter is just to use the current date if there is none specified. I think it would be fine to keep that and allow apply even if the date input is empty.

authors: laurakwhit rossedfort

repo: temporalio/ui


text:
How to restore a face in the correct way?

I'm using IP-Adapter + ControlNet with Normal maps:

IPAdapterPlus
base_model_path = "SG161222/Realistic_Vision_V6.0_B1_noVAE"
vae_model_path = "stabilityai/sd-vae-ft-mse"
image_encoder_path = "models/image_encoder/"
ip_ckpt = "models/ip-adapter-plus_sd15.bin"
E.g.
And I received a good picture, but in the photo, I don't look like myself at all.

I also tried
ip_ckpt = "models/ip-adapter-plus-face_sd15.bin"
the result is:

And tried face models, e.g.:
ip_ckpt = "models/ip-adapter-faceid-plus_sd15.bin"
my face extracted in a good way,

but the result is:

How can I achieve better results?
Appreciate your help

do some high resolution fix

Should High resolution be applied to a face or the whole image?
Initially, I tried with image 1280x961

the result is:

In the above example, the image has a resolution of 3000x4000.

repo: tencent-ailab/IP-Adapter


text:
introduces transcipt hashing to secret connection.

Breaks compatibility with legacy secret connection.
Companion to https://github.com/tendermint/tendermint/pull/3668
Integration tests should fail.

This PR needs to get reopened here as the relevant code has moved:
https://github.com/interchainio/tendermint-rs

authors: tarcieri zmanian

repo: tendermint/kms


text:
🛑 Beeldoverleg Website is down

In 663bad1, Beeldoverleg Website (https://beeldoverleg.nl) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Beeldoverleg Website is back up in fd27560 after 10 minutes.

repo: tendsgn/upptime


text:
🛑 Beeldoverleg Website is down

In 19c7816, Beeldoverleg Website (https://beeldoverleg.nl) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Beeldoverleg Website is back up in ec214aa after 6 minutes.


text:
feat(CI): Enable macOS continuous build

Description

We enable macOS build only when there is a new release.
Now we get unlimited github action minutes. Lets enable it for every PR

repo: tensorchord/envd