Skip to content

Provide beta images #14

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

Open
mzabaluev opened this issue Dec 3, 2017 · 12 comments
Open

Provide beta images #14

mzabaluev opened this issue Dec 3, 2017 · 12 comments

Comments

@mzabaluev
Copy link

It would be nice to have an official repository of up-to-date Rust beta images, to complete the rustup-like trifecta for automated CI runs and the like.

@sfackler
Copy link
Member

sfackler commented Dec 3, 2017

Seems reasonable to me!

sfackler added a commit that referenced this issue Dec 3, 2017
sfackler added a commit that referenced this issue Dec 3, 2017
@sfackler sfackler mentioned this issue Dec 3, 2017
sfackler added a commit that referenced this issue Dec 3, 2017
@marcelbuesing
Copy link

I think it would be great to have beta images. Would make sense to update to the current version. Given the frequency of beta updates I assume even some automation would make sense otherwise it's probably outdated within a couple of days, weeks.

@TimDiekmann
Copy link
Member

I did some tests for all three toolchains, fully automated:

Three jobs:

  • env: TOOLCHAIN=stable
  • env: TOOLCHAIN=beta
  • env: TOOLCHAIN=nightly

First of all, it pulls the current image:

docker pull $REPOSITORY/$IMAGE_NAME:$TOOLCHAIN || true

then the current version is determined:

RUSTC_PULLED=$(docker run $REPOSITORY/$IMAGE_NAME:$TOOLCHAIN rustc --version || true)

Now the new image is generated:

- docker build --rm -t$REPOSITORY/$IMAGE_NAME --build-arg TOOLCHAIN=$TOOLCHAIN .
- RUSTC_GENERATED=$(docker run $REPOSITORY/$IMAGE_NAME rustc --version)

The deploy process is locked behind checking the versions to avoid unnecessary deploying:

deploy:
  provider: script
  script:
    - docker push $REPOSITORY/$IMAGE_NAME
  on:
    branch: master
    condition: $RUSTC_PULLED != $RUSTC_GENERATED

before deploying, the tags are generated:

- docker tag $REPOSITORY/$IMAGE_NAME $REPOSITORY/$IMAGE_NAME:$TOOLCHAIN
- if [[ $TOOLCHAIN = beta || $TOOLCHAIN = nightly ]]; then
    docker tag $REPOSITORY/$IMAGE_NAME $REPOSITORY/$IMAGE_NAME:$TOOLCHAIN;
    docker rmi $REPOSITORY/$IMAGE_NAME;
  fi

@sfackler
Copy link
Member

These images aren't pushed directly - it's managed through the docker-library/official-images repository.

@TimDiekmann
Copy link
Member

Is there a limitation, how often an image can be pushed to the official repo?
Is this done with ~/official-images/test/run.sh "$image"?

@sfackler
Copy link
Member

It's done by opening a pull request to that repository. For example docker-library/official-images#5048

@TimDiekmann
Copy link
Member

Oh, automation would be hard then anyway, right?

@tyranron
Copy link
Contributor

For those who needs beta Rust Docker images, consider to use instrumentisto/rust Docker images. They try to reuse/follow official Rust Docker images as much as possible.

@Venryx
Copy link

Venryx commented Apr 3, 2022

For those who needs beta Rust Docker images, consider to use instrumentisto/rust Docker images. They try to reuse/follow official Rust Docker images as much as possible.

It's helpful that your group is providing these Docker images publicly (as it makes using the beta versions of Rust easier), but it might be worth clarifying the identity of the instrumentisto GitHub org so that people can trust it more.

I'm a bit hesitant to do so with there being only one user in the organization (publicly visible anyway), and without an explanation text of who they are or what their motivation is for building and releasing these images.

@tyranron
Copy link
Contributor

tyranron commented Apr 3, 2022

@Venryx it's not a concrete organization, but more like a team of people which are/were sharing the same job. Projects there are/were created to solve needs for their jobs, and open sourced, because "why not? someone may use out of it" 🙃

As for "publicly visible" members, it's just they don't bother about it. I've found myself being not publicly visible there only few months ago, while participating there for years. It was just an accident that I saw my profile unathenticated, and only then checked settings where participation visibility was assigned private by default. You may check last contributions to projects there, so this way you will see who are actual active members. We very rarely have contributions outside.

If you're still hesitant about it and/or my statement is not enough, then it's okay for me/us too. We're not advocating for ourselves. It's open source by the way.

@Venryx
Copy link

Venryx commented Apr 3, 2022

@tyranron Ah okay, thanks for the info! That makes sense to check the contribution lists for more details. :)

@tgross35
Copy link

tgross35 commented Oct 2, 2022

Is the issue here just that it is lacking some sort of automatic composibility? I wonder if there's a project that could be borrowed from.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants