Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Override network mtu value #1

Draft
wants to merge 116 commits into
base: v2
Choose a base branch
from
Draft

Override network mtu value #1

wants to merge 116 commits into from

Conversation

aledbf
Copy link
Member

@aledbf aledbf commented Apr 16, 2022

Do not merge. We only need to rebase the PR after each docker-compose release and release a new version.

@AaronDewes
Copy link

It seems like you modified the version to be 2.4.1.2-gitpod in the version running in Gitpod.
I am writing a program which checks the compose version before running using python-semver 2.4.1.2-gitpod is not a valid semver, so this fails on Gitpod. Please use a valid semver like 2.4.1-gitpod.2 to keep compatibility with the upstream compose. (I can also open an issue if the main Gitpod repo if you want)

@aledbf
Copy link
Member Author

aledbf commented May 2, 2022

@AaronDewes thank you for mentioning this issue. We are updating docker compose to v2.5.0 in the next deployment and we will fix the semver problem. Apologies for the issue.

xref gitpod-io/gitpod#9699

@kylos101
Copy link

@aledbf is this still needed? If we're never going to merge, can it be converted to draft?

@aledbf
Copy link
Member Author

aledbf commented Aug 22, 2022

We are never going to merge this PR. The idea here is to rebase it after any release from the original repository and update the binary like was being done for the last eight releases.

@aledbf aledbf force-pushed the custom-mtu branch 2 times, most recently from 9e203ae to 81854eb Compare August 22, 2022 20:00
@kylos101 kylos101 marked this pull request as draft February 20, 2023 22:04
@kylos101
Copy link

@aledbf we're a few versions behind on docker compose (2.10.0 -> 2.16.0). I don't have bandwidth to update and test this week, but wanted to check.

Are we staying on an older version intentionally? Or should I plan to update as time permits in the future?

Cc: @Furisto and @akosyakov for 👀

@kylos101
Copy link

kylos101 commented May 22, 2023

@aledbf I am updating our instructions here, also below, to make managing our fork easier.

The # of commits is still too high, though. 🤔 What am I doing wrong? Steps I took:

# set go version
cd $HOME
export GO_VERSION=1.20.4
rm -rf /home/gitpod/go-packages
rm -rf /home/gitpod/go
sudo rm -rf $GOPATH/src $GOPATH/pkg $HOME/.cache/go $HOME/.cache/go-build
curl -fsSL https://dl.google.com/go/go$GO_VERSION.linux-amd64.tar.gz | tar xzs
go install -v github.com/uudashr/gopkgs/cmd/gopkgs@v2 \
&& go install -v github.com/ramya-rao-a/go-outline@latest \
&& go install -v github.com/cweill/gotests/gotests@latest \
&& go install -v github.com/fatih/gomodifytags@latest \
&& go install -v github.com/josharian/impl@latest \
&& go install -v github.com/haya14busa/goplay/cmd/goplay@latest \
&& go install -v github.com/go-delve/delve/cmd/dlv@latest \
&& go install -v github.com/golangci/golangci-lint/cmd/golangci-lint@latest \
&& go install -v golang.org/x/tools/gopls@latest \
&& go install -v honnef.co/go/tools/cmd/staticcheck@latest
cd -

# to update the fork, please rebase, do not merge
git checkout custom-mtu
git fetch upstream --tags
# rebase on the tag related to the release, for example:
# FYI, you'll have to resolve a conflict with go.mod, accept it as incoming, we need the change with github.com/vishvananda/netlink
git rebase v2.18.1
go mod tidy

# tag like v<docker-compose-version>-gitpod.<tag-instance>
git tag v.2.18.1-gitpod.0
git push origin --tags

@aledbf aledbf force-pushed the custom-mtu branch 4 times, most recently from 3c24ca7 to 7accbf3 Compare May 22, 2023 22:40
@aledbf
Copy link
Member Author

aledbf commented May 22, 2023

@kylos101 due to the number of changes and being an external repository, I do this:

  • Sync the fork using the button that appears in the repo
  • Run
git checkout custom-mtu
git format-patch -i <previous commit to our changes> #now is cd0fc214a5a9b07cbe6e262398d0e9dc8603b81b
git branch -m old
git checkout v2.18.1
git switch -c custom-mtu # use v2.18.1 as the base branch (or the version you want to publish)
git am *.patch
git push --set-upstream origin custom-mtu --force

ndeloof and others added 26 commits April 15, 2024 22:05
This reverts commit a4ddbcb.

Signed-off-by: Nicolas De Loof <[email protected]>
When creating automatic file shares, ignore any non-directory
bind mounts, e.g. for an individual (normal) file or a special
type like a Unix socket (`/var/run/docker.sock`).

Additionally, there's no need to create a directory if one
does not exist, the API will handle that. However, the check
for existence remains so that `create_host_path: false`
mounts can be ignored.

Signed-off-by: Milas Bowman <[email protected]>
Signed-off-by: Nicolas De Loof <[email protected]>
…trl-C on compose up (docker#11719)

Ensure done channel is closed only once

Signed-off-by: Jaime Soriano Pastor <[email protected]>
Signed-off-by: Nicolas De Loof <[email protected]>
fix support for `--flag=value` syntax in compatibility mode
* `moby/buildkit` commit comes from `docker/buildx`
* v26.1-dev from `moby/moby` & `docker/cli`

Signed-off-by: Milas Bowman <[email protected]>
This was racy with the sleep, so the Compose file has been
tweaked to make it pass reliably.

Now, there's 3 services:
 * `running` - sleeps forever
 * `exit` - exits _successfully_ immediately
   * depends on `running` started
 * `fail` - exits _with error_ immediately
   * depends on `exit` succeeding

Now, the test can ensure that the containers are all run/
started in the expected order the assertions will be reliable.

Before, it was possible for `fail` to run & exit before `exit`,
for example. The `running` service also ensures there's always
at least one other "running" container when we do an abort.

Signed-off-by: Milas Bowman <[email protected]>
chore(e2e): fix flaky cascade failure test
Bumps [github.com/moby/buildkit](https://github.com/moby/buildkit) from 0.13.0-rc3.0.20240417151852-71f99c52a669 to 0.13.1.
- [Release notes](https://github.com/moby/buildkit/releases)
- [Commits](https://github.com/moby/buildkit/commits/v0.13.1)

---
updated-dependencies:
- dependency-name: github.com/moby/buildkit
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <[email protected]>
…hub.com/moby/buildkit-0.13.1

build(deps): bump github.com/moby/buildkit from 0.13.0-rc3.0.20240417151852-71f99c52a669 to 0.13.1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet