This merge request rename stable builds from tagged release from stable to latest, and renamed containers build from main branch from latest to nightly to match container image naming conventions.
Renovate Bot (d920dc7c) at 26 Mar 21:16
chore(deps): update module github.com/aws/aws-sdk-go-v2/credentials...
... and 2 more commits
Renovate Bot (d4bab8b2) at 26 Mar 21:16
chore(deps): update module github.com/aws/aws-sdk-go-v2/config to v...
... and 2 more commits
Two issues were causing the pipeline to not properly tag the release:
tag-container-release
job needs to depend on the previous stages so there is a container to tagThis should address the issue noted in #40345
This change set copy snowflake container repo to Dockerhub each time there is a new image potentially available.
Will be marked as ready after the current bug with snowflake container building is fixed.
Sounds good, let's merge it then.
As usual in programming the hardest part is to set a good name for it.
It looks like a utils library, maybe ptutil? I tend dislike calling modules util as it ends up being a mess of incoherent pieces. But maybe this is what we are creating here.
Another option is to go for the 'safe-' side, as they are safelog and safeprometheus :) The best I can come up with that line is safetools, safeutils, safept. Not so great, I guess ptutil is better.
Any better ideas for names?
RoundCounter is a useful wrapper on top of prometheus to round metrics to 8. We want to use it in other projects like rdsys.
Another useful piece for other projects is safelog that is already being imported by bridgestrap and conjure. Maybe we want to be able to import it without snowflake.
We could bundle both into a single library as this might make it easier to add other pieces in the future and each extra library makes it harder to package software to distros.
The current container image tag for container images built from main branch is latest, which is typically expected to the most recent stable release, instead of the unstable main branch build result. The tag should be renamed to nightly
as discussed in the during the weekly meeting.
There was some time before I worked on this merge request last time. Look at it again I realize there are some alternative design that would address the issue of the need to create a separate channel unnecessarily for now.
The alternative plan will be:
turbotunnel.ClientID
, in addition to the transportation mode it currently has.In this way, we not only sent client ID via label or other channel to the server before the client send any message, we also make proxy a dumb pipe that do not process any information other than the transportation protocol. So it will not stall future updates.
Renovate Bot (a016c8b5) at 25 Mar 14:47
chore(deps): update module github.com/aws/aws-sdk-go-v2/credentials...
... and 1 more commit
Renovate Bot (bee6dc20) at 25 Mar 14:47
chore(deps): update module github.com/aws/aws-sdk-go-v2/config to v...
... and 1 more commit
We switched to a CDN77, a cloud provider that supports domain fronting.
Cecylia Bocovich (96422e0d) at 25 Mar 14:23
Update torrc file to match Tor Browser builtins
I think it is not expected leak token, and the account associated with it already only have access to work related repos.
I merge this after prerequisite MR are processed.
The password echoed in plain text are always expected to be removed from log. It only become problematic when it get modified.
I already plan to use my work related dockerhub account(shelikhoo@torproject.org) for this, so the damage it could create will be limited. I didn't find a way to create token with usage scoped to certain repository.
I will merge this after !279 (diffs), and the proposed change about renaming containers main branch build to nightly
, and after at least one tagged release to get a proper latest
... that was a lot of terms and quotation marks...
Looks good to me. Just one comment about leaking passwords. Otherwise I think is good to merge.
I guess we should create an account in docker hub for the CI, so if it gets compromised (like gitlab having a security issue) we can roll it without using our own accounts.