Simplify & introduce versioning #83

meeDamian · 2019-08-15T12:30:13Z

This PR simplifies the build process, and introduces git-tag-based versions to Docker tags.

Most specifically, each successful GIT TAG build results in Docker deployment that pushes two Docker tags for each built image:

one moving, that is updated with each new passing build, ex. :latest, :register, or :arm, and
one version-specific, that will never change, ex :v4.0.0-5, :register-v4.0.0-5, or :arm-v4.0.0-5.

Other changes:

Github release deployment now happens using native deploy mechanism,
Docker push happens only if build was triggered by pushing a git tag,
All x86_64_ prefixes are stripped since, as of now it's the only supported architecture anyway,
Triggering build of a new version is as simple as this, namely:
1. Adjust URL in .travis.yml file to point to the newest qemu release
2. Commit said line change, ex:
```
git add .travis.yml
git commit -m 'qemu version bumped to X'
```
3. Tag & push, ex:
```
git tag -sa v4.0.0-5 -m "v4.0.0-5" 
git push origin v4.0.0-5
```
4. Wait :)
Travis needs to be configured with DOCKER_USER, and DOCKER_PASS environment variables.

Github deployment

Note, since I don't have write rights to this repository, api_key used here needs to be regenerated by someone who does have access :). The easiest way I've found to do it so far is:

cd qemu-user-static/
travis setup releases --com

Unfortunately, running this command has a nasty habit of changing .yml file a bit more than necessary, so I advice just copying the encrypted API key from there, and pasting it to the restored file.

Outcomes

You can see how successful releases & Github uploads look like here: https://github.com/meeDamian/qemu-user-static/releases .

All Docker tags pushed during Travis builds can be found here: https://hub.docker.com/r/meedamian/qemu-user-static/tags

Happy to hear feedback. The issue that inspired me to get to it was #74 .

meeDamian · 2019-08-15T12:32:05Z

I've noticed you use travis-ci.org, as opposed to travis-ci.com, in which case the --com flag to the travis setup command should not be used :).

junaruga · 2019-08-15T13:40:39Z

Hi @meeDamian , I really appreciate your contribution!

Yes, the versioning is very important feature with high priority for this project.

I proposed the feature at below ticket too.
#74 (comment)

I will take a look at your code later.
But please be patient as I will be in vacation next week. :)

Thank you!

junaruga · 2019-08-15T13:43:04Z

I've noticed you use travis-ci.org, as opposed to travis-ci.com, in which case the --com flag to the travis setup command should not be used :).

Yes "travis-ci.org" is used for a free Travis CI plan. Open source project uses it. "travis-ci.com" is for non-free paid Travis CI plan. :)

junaruga · 2019-08-15T13:47:44Z

In a mean time, is it possible to do squash current 9 commits to 1 commit by git rebase -i <commit hash> and etc to make the code review easier? Is there a reason to keep the commits?

meeDamian · 2019-08-15T18:45:46Z

I had the commits so that I could generate git tags for qemu versions, trigger and reference Travis builds, and docker hub tags.

That being said, I've moved them to another branch and squashed in this one :).

meeDamian · 2019-08-15T18:51:35Z

Note that the most recent build overrides all floating Docker tags, so it's best to push said tags in strictly increasing order.

moul

Awesome! :)

junaruga · 2019-08-15T20:07:42Z

@moul Wow, thanks for the quick review. :) Could you give me a time for my review?

moul · 2019-08-15T20:53:09Z

yep sure, I was mostly approving the overall approach, I may have miss some details, take the time you need :)

junaruga · 2019-08-15T21:57:27Z

@moul Thanks.

@meeDamian Your approach to simplify is amazing! Thank you.

Let's me comment on one by one.
First about a big picture.

Image tag version format

one version-specific, that will never change, ex :v4.0.0-5, :register-v4.0.0-5, or :arm-v4.0.0-5

I would prefer "ex :v4.0, :register-v4.0, or :arm-v4.0" than "ex :v4.0.0-5, :register-v4.0.0-5, or :arm-v4.0.0-5".

Because

Reason 1: I want to consider to align with our sister project: https://github.com/dbhi/qus (DockerHub: https://hub.docker.com/r/aptman/qus/tags) with a balancing.
In aptman/qus, the tag is f4.0.0 (from fedora qemu) or d3.1 without a qemu package release number.
Reason 2: To save the number of containers as our project's small start.

That means below kind of logic to replace v3.1.0-3 with v3.1 or v4.0.0 with v4.0 is needed at early step.

TAG_VERSION=$(echo  ${TRAVIS_TAG} | sed 's/something/something/')

Pipeline to rerun already git tagged version

While the pipeline based on TRAVIS_TAG is great, the pipeline can be failed because of some issue.
And maybe we also want to run old tag's pipeline to upload old qemu version's tag.
That means below kind of logic might be useful.

TAG_VERSION=${TAG_VERSION-TRAVIS_TAG}

When people want to rerun or run for old qemu version, we can set like this in .travis.yml.

ADHOC_TAG=v3.1.0-3
TAG_VERSION=${ADHOC_TAG:-TRAVIS_TAG}

In that case, the deploy condition might be like this.

  - name: deploy
    if: tag IS present OR <ADHOC_TAG is not empty>

x86_64 prefix

All x86_64_ prefixes are stripped since, as of now it's the only supported architecture anyway,

I disagree for this change. Please keep the prefix.
https://github.com/multiarch/qemu-user-static/releases

We have already released the x86_64 prefix tar.gz x86_64_qemu-aarch64-static.tar.gz.
Changing the prefix breaks backward compatibility.
Users are confused as a possibility.

x86_64 prefix is to implement new host arch's container images or tar.gz on GitHub releases.
Now only x86_64 are supported. It's for future's preparation.

Now we are trying to implement other arch host's images and tar.gz files, that are aarch64, s390x prefix and etc.
#77

I like that below .gitignore modification is reverted.

-/containers/x86_64_qemu-*/
+/containers/qemu-*/

Detail

I comment it on the line.

junaruga · 2019-08-15T21:59:06Z

.gitignore

@@ -4,5 +4,5 @@
 /containers/latest/qemu-*-static
 /containers/register/Dockerfile
 /containers/register/register.sh
-/containers/x86_64_qemu-*/
+/containers/qemu-*/


As I commented in big picture section, I prefer keeping x86_64 prefix, because we are trying support other host arch now. I like to see that this modification in .gitignore is reverted.

This dir is rm -rf-ed after each loop iteration: https://github.com/meeDamian/qemu-user-static/blob/simplify/build-docker.sh#L61, so frankly speaking a completely static name could be used for it. As a matter of fact, I think it might be even better, and simpler.

junaruga · 2019-08-15T22:01:46Z

.travis.yml

@@ -3,42 +3,49 @@ services: docker
 language: bash


You changed your new modification with 2 spaces indent. But this .travis.yml YAMP file was managed with 4 spaces indent. Please change your modification in .travis.yml to 4 spaces.

junaruga · 2019-08-15T22:02:40Z

.travis.yml

@@ -3,42 +3,49 @@ services: docker
 language: bash
 addons:
    apt:
-        config:
-            retries: true


Why did you remove the lines? I added the lines referring ruby/ruby's .travis.yml.
https://github.com/ruby/ruby/blob/master/.travis.yml#L120

My IDE says this property is not allowed there. I wasn't able to find any documentation about it. Everything worked well without it. I'm happy to add it back if it actually does something, or is useful :).

Please back it.

When "My IDE says this property is not allowed there", removing it is not good choice.

As you may know Travis is open source and written in Ruby language. In Ruby project, the core maintainers communicate with a core member on Travis project in Ruby project. As a result, the feature that is not documented, only existed in the source code can be used for Ruby project as a possibility. Ruby project uses .travis.yml with very advanced way.

junaruga · 2019-08-15T22:15:31Z

.travis.yml

+        file_glob: true
+        file: releases/*.tgz
+        on:
+          repo: ${TRAVIS_REPO_SLUG}


This line means the container image's URL that is used for docker push, right?
Not everyone's GitHub (owner_name/repo_name) including forked repository equals the image URL (owner_name/repo_name) on DockerHub.

The logic is to consider the cases to give users options.
In my opinion, DockerHub has a problem for the security than quay.io.

- DOCKER_SERVER=docker.io # - DOCKER_SERVER=quay.io # Git repository - REPO=multiarch/qemu-user-static # Container repository - DOCKER_REPO=$DOCKER_SERVER/multiarch/qemu-user-static

My development container repository is here quay.io/junaruga/qemu-user-static.
https://quay.io/repository/junaruga/qemu-user-static?tab=info
The container server information is necessary.

When someone already have qemu-user-static repository, the forked repository from this repository is username/qemu-user-static-1.

That line (and entire deploy: section here) has nothing to do with Docker. This is a Travis-provided line that contains Github's SLUG ex. multiarch/qemu-user-static so that deploy knows where to upload the tarballs.

junaruga · 2019-08-15T22:26:24Z

.travis.yml

-        - REPO=multiarch/qemu-user-static
-        # Container repository
-        - DOCKER_REPO=$DOCKER_SERVER/multiarch/qemu-user-static
-        # - DOCKER_REPO=$DOCKER_SERVER/your_username/qemu-user-static


Please keep VERSION (For adhoc pipline), DOCKER_SERVER, REPO, DOCKER_REPO.
In general, it's not only for this project, I think that a good strategy to send pull-request, is "1 pull-request, 1 feature".
You changed a lot including some features.

The reason why 1 pull-request, 1 feature strategy is better is you can proceed your work understanding project people's needs and intentions towards your final goal.
The output becomes "1 commit 1 feature". The merit of this is if the new commit has a issue, we can revert the commit later.

Though I understand the each feature in this PR is great.

I am thinking how we can proceed this PR.

Everything was commented out, and defaults were used. I thought that in a case like this it's simpler to start with a cleaner slate, and then gradually add features, as they become needed at the time.

Also, not sure what "adhoc pipline" means, and how and what version to add 🤔

junaruga · 2019-08-15T22:31:28Z

test.sh

-    exit 1
-fi
+# Convert Travis-provided repo SLUG to lowercase - Docker's requirement for tags
+SLUG="$(echo "${TRAVIS_REPO_SLUG}" | tr '[:upper:]' '[:lower:]')"


TRAVIS_REPO_SLUG does not always container repository's URL. Please keep DOCKER_REPO in this file.

junaruga · 2019-08-15T22:34:21Z

build-docker.sh

@@ -0,0 +1,92 @@
+#!/usr/bin/env bash


I do not like the file name build-docker.sh.
The reason is

shell scripts in this project is alphabet (small letter) + underscore as a separator.

"docker" is product name. "containers" are already used as a output directory name for the purpose.

I prefer the file name build_containers.sh.

This project's shell scripts are 4 spaces indent mainly. See removed publish.sh and removed lines in test.sh.
So, keep 4 spaces indent on shell scripts (*.sh).

junaruga · 2019-08-15T22:37:55Z

build-docker.sh

@@ -0,0 +1,92 @@
+#!/usr/bin/env bash
+set -xe


If you use pipe | in the shell script, consider pipefail.

#!/usr/bin/env bash set -xeo pipefail

junaruga · 2019-08-15T22:38:25Z

build-docker.sh

+# Convert Travis-provided repo SLUG to lowercase - Docker's requirement for tags
+SLUG="$(echo "${TRAVIS_REPO_SLUG}" | tr '[:upper:]' '[:lower:]')"
+
+#


You forget comment here?

Not sure if necessary, I'll just remove the line :)

junaruga · 2019-08-15T22:40:17Z

build-docker.sh

+
+
+# Convert Travis-provided repo SLUG to lowercase - Docker's requirement for tags
+SLUG="$(echo "${TRAVIS_REPO_SLUG}" | tr '[:upper:]' '[:lower:]')"


Please do not use SLUG (Github's owner_name/repo_name) as docker repo. The reason is as I wrote at other part.
Please keep using DOCKER_REPO in the file instead.

junaruga · 2019-08-15T22:40:48Z

generate_tarballs.sh

@@ -1,11 +1,17 @@
-#!/bin/bash -e
+#!/usr/bin/env bash


You need "-e" here, keep compatibility.

Adding -e to #!/usr/bin/env bash breaks everything. AFAIK using #!/usr/bin/env bash is recommended. I have no idea what -e does, I'm happy to go with anything you recommend :).

I do not object with #!/usr/bin/env bash.
It is certainly a good practice

In a case of people want to run a bash script on the environment where /bin/bash does not exist. But I wonder if there is the Linux or UNIX distribution that do not have it today. Because /bin/ is standard rule of Linux system. Ref: https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard .

I a case of people want to run a shell script on the different path's bash that is source compiled bash.

The down side of #!/usr/bin/env bash is different path's bash is unintentionally executed.

I am not a original coder who wrote #!/bin/bash. But you should feel original coder's good intent for the code. At least you should not include the change of #!/usr/bin/env bash in this PR. Because it's not harmful.
For each change especially for non backward compatibility feature, we need discussion.

I have no idea what -e does, I'm happy to go with anything you recommend :).

You do not know bash -e? It's quite important feature to make the bash script defensive. It's similar with set -e. man bash might explain you.

When you have no idea what something does, proceeding removing it is not good choice.

junaruga · 2019-08-15T22:45:57Z

I think we do not include TRAVIS_TAG and TRAVIS_REPO_SLUG variables in '*.sh".
Because we (at least me) want to run the shell scripts on my local environment.

If you keep below variables, it is possible not to use the TRAVIS-* in .*.sh.

-    global:
-        - VERSION=4.0.0-5
-        # See qemu-user-static's RPM spec file on Fedora to check the new version.
-        # https://src.fedoraproject.org/rpms/qemu/blob/master/f/qemu.spec
-        - DOCKER_SERVER=docker.io
-        # - DOCKER_SERVER=quay.io
-        # Git repository
-        - REPO=multiarch/qemu-user-static
-        # Container repository
-        - DOCKER_REPO=$DOCKER_SERVER/multiarch/qemu-user-static
-        # - DOCKER_REPO=$DOCKER_SERVER/your_username/qemu-user-static
-        - PACKAGE_URI="https://kojipkgs.fedoraproject.org/packages/qemu/4.0.0/5.fc31/x86_64/q
emu-user-static-4.0.0-5.fc31.x86_64.rpm"
-        - PACKAGE_FILENAME=$(basename "$PACKAGE_URI")

Keep docker images that is after building containers on local.
That's useful to check actual created containers with tags.

junaruga

I commented many points. :)
I appreciate your work for this PR.
But I think basically "1 PR 1 feature" one by one. was better approach to make your and reviewer's work easier.

You are harder to fix when you send 1 PR including several features.

junaruga · 2019-08-15T23:17:00Z

Travis needs to be configured with DOCKER_USER, and DOCKER_PASS environment variables.

We are already running with DOCKER_PASSWORD in this repository.
I do not think it is necessary change for this PR.

junaruga · 2019-08-16T00:25:17Z

Sorry @meeDamian I sent another PR to implement versioning with minimal steps.
#84

I think you want to see it is implemented soon.
But I think we need more time to accomplish this PR.

After #84 is merged, I want to see this PR focusing only the one feature "simplifies the build process", keeping current implementations that have good intentions.

Thank you for your understanding.

junaruga · 2019-08-16T01:04:51Z

.travis.yml

+jobs:
+  include:
+    - stage: build
+      name: "Build Docker image for amd64"


Can you change "Build container images for x86_64"?
Because "x86_64" and "container" are already used in other parts and manual. "Docker" is product name.

meeDamian · 2019-08-16T06:07:32Z

Image tag version format

one version-specific, that will never change, ex :v4.0.0-5, :register-v4.0.0-5, or :arm-v4.0.0-5

I would prefer "ex :v4.0, :register-v4.0, or :arm-v4.0" than "ex :v4.0.0-5, :register-v4.0.0-5, or :arm-v4.0.0-5".

Because

Reason 1: I want to consider to align with our sister project: dbhi/qus (DockerHub: hub.docker.com/r/aptman/qus/tags) with a balancing.
In aptman/qus, the tag is f4.0.0 (from fedora qemu) or d3.1 without a qemu package release number.

Reason 2: To save the number of containers as our project's small start.

That means below kind of logic to replace v3.1.0-3 with v3.1 or v4.0.0 with v4.0 is needed at early step.
TAG_VERSION=$(echo  ${TRAVIS_TAG} | sed 's/something/something/')

The issue with that is that my original problem would remain unsolved with this approach: v4.0.0-5 didn't work work me, but v4.0.0-4 did.

What I can do, is to add an extra floating vMAJOR-MINOR tag that always points to the latest MINOR version. It's a very common practice in Docker, because that gives one the flexibility to use a specific version, as well as stay always-up-to-date stay on a chosen minor version.

meeDamian · 2019-08-16T06:17:01Z

Pipeline to rerun already git tagged version

While the pipeline based on TRAVIS_TAG is great, the pipeline can be failed because of some issue.
And maybe we also want to run old tag's pipeline to upload old qemu version's tag.
That means below kind of logic might be useful.
TAG_VERSION=${TAG_VERSION-TRAVIS_TAG}
When people want to rerun or run for old qemu version, we can set like this in .travis.yml.
ADHOC_TAG=v3.1.0-3
TAG_VERSION=${ADHOC_TAG:-TRAVIS_TAG}
In that case, the deploy condition might be like this.
  - name: deploy
    if: tag IS present OR <ADHOC_TAG is not empty>

I think there are several issues with that, that would necessitate adding further complexity, ex: What to do with github release uploads? If there's no git tag, there's no place for them to go.

Also, I like the consistency of github tags corresponding directly to releases, and docker version tags. Keep in mind that changing binary version is now literally a single line change in the .travis.yml file.

Namely, if you do what I did with bump qemu… commits here: https://github.com/meeDamian/qemu-user-static/commits/simplify-with-tags, tag them all appropriately, and push all tags - everything will fall in place nicely.

meeDamian · 2019-08-16T06:18:44Z

x86_64 prefix

All x86_64_ prefixes are stripped since, as of now it's the only supported architecture anyway,

I disagree for this change. Please keep the prefix.
multiarch/qemu-user-static/releases

We have already released the x86_64 prefix tar.gz x86_64_qemu-aarch64-static.tar.gz.
Changing the prefix breaks backward compatibility.
Users are confused as a possibility.

x86_64 prefix is to implement new host arch's container images or tar.gz on GitHub releases.
Now only x86_64 are supported. It's for future's preparation.

Now we are trying to implement other arch host's images and tar.gz files, that are aarch64, s390x prefix and etc.
#77

I like that below .gitignore modification is reverted.
-/containers/x86_64_qemu-*/
+/containers/qemu-*/

Ok, no problem :)

Do you want to have two versions: one with the prefix, and one without? Or is just one with the prefix sufficient?

meeDamian · 2019-08-16T06:54:12Z

I think we do not include TRAVIS_TAG and TRAVIS_REPO_SLUG variables in '*.sh".
Because we (at least me) want to run the shell scripts on my local environment.

If you keep below variables, it is possible not to use the TRAVIS-* in .*.sh.

-    global:
-        - VERSION=4.0.0-5
-        # See qemu-user-static's RPM spec file on Fedora to check the new version.
-        # https://src.fedoraproject.org/rpms/qemu/blob/master/f/qemu.spec
-        - DOCKER_SERVER=docker.io
-        # - DOCKER_SERVER=quay.io
-        # Git repository
-        - REPO=multiarch/qemu-user-static
-        # Container repository
-        - DOCKER_REPO=$DOCKER_SERVER/multiarch/qemu-user-static
-        # - DOCKER_REPO=$DOCKER_SERVER/your_username/qemu-user-static
-        - PACKAGE_URI="https://kojipkgs.fedoraproject.org/packages/qemu/4.0.0/5.fc31/x86_64/q
emu-user-static-4.0.0-5.fc31.x86_64.rpm"
-        - PACKAGE_FILENAME=$(basename "$PACKAGE_URI")

If you run the script with:

TRAVIS_REPO_SLUG=multiarch/qemu-user-static ./test.sh

it should work, that being said I'm happy to add fallback to all TRAVIS_ vars in .sh: ${TRAVIS_REPO_SLUG:-$REPO}, or hardcoded ${TRAVIS_REPO_SLUG:-multiarch/qemu-user-static}. Main reason I've added TRAVIS_ vars there is because I couldn't get .travis.yml-defined global vars to be available in scripts.

Keep docker images that is after building containers on local.
That's useful to check actual created containers with tags.

👍🏻

meeDamian · 2019-08-16T07:08:25Z

I think I've addressed most issues, but I would still like to know what exactly you want to achieve with the adhoc pipeline?

meeDamian · 2019-08-16T07:40:18Z

Ah could you also explain the :register image to me? It's not exactly clear what it does, or what it is useful for to me, thank you :).

junaruga · 2019-08-16T07:41:11Z

I think I've addressed most issues, but I would still like to know what exactly you want to achieve with the adhoc pipeline?

I used "adhoc pipeline" means the one without "git" tagging", and same with "Pipeline to rerun already git tagged version".

meeDamian · 2019-08-16T07:42:22Z

You can do that from Travis's interface, can't you?

junaruga · 2019-08-16T07:49:12Z

You can do that from Travis's interface, can't you?

For rerun, it is possible from Travis interface.
But it is not enough when running past tagged qemu version with latest fixes and features.

The scenario of commits is

Run pipeline with version A.
Add commit to fix to a bug.
Add commit to add new feature
Run pipeline with version B.
Then rerun pipeline with version A with above fix and the new feature.

meeDamian · 2019-08-16T08:05:24Z

Thank you, that makes it clearer :).

The only question I have is wouldn't that warrant a new git tag? Either an extra one, or previous one changed to point to the correct source version. Otherwise you have a case where containers shipped, are not what the source code would claim they are.

To use your scenario:

Run pipeline with version A (say v4.0.0).
Add commit to fix to a bug.
Add commit to add new feature
Create a new git tag
1. Either something along the lines of v4.0.0-bugfix-1, if you want previous version to be preserved as well, or
2. delete previous tag, and create it anew for the now fixed, and correct source
Run pipeline with version B.
~~Then rerun pipeline with version A with above fix and the new feature.~~ Push the tag

The issue with that, in both approaches, is that build A would overwrite the floating tags, even if version B is newer. I reckon the easiest way to address that would be to:

Each fix commit of this nature, would also add BUGFIXBUILD=true in .travis.yml, which would prevent overwriting of any floating tags, or
Before each bugfix build said variable is added to build config variables in Travis's interface.

In both cases the variable needs to be removed after the build.

junaruga · 2019-08-16T09:22:30Z

Ah could you also explain the :register image to me? It's not exactly clear what it does, or what it is useful for to me, thank you :).

It's only to add binfmt_misc files with "flags: " (empty).
binfmt_misc file is a special file, that is a Linux kernel feature. The benefit of the file is people can run arch specific binary (= arch container) without specifying the qemu interpreter file (qemu-$arch-static file).

The register image was the only way to run arch container until a few weeks ago, until "mutlarch/qemu-user-static" (latest) was released.
I think still many people using the register image.
And I can imagine register image is preferred than "mutlarch/qemu-user-static" in some cases for people who wants to create the minimal resourced (memory and disk size) container image.

You can refer README.md and Developers Guide under does/ directory.

junaruga · 2020-07-14T11:42:55Z

Thank you for your contributing. Let me close this big PR at once.

meeDamian · 2020-07-16T12:37:56Z

Long overdue :). Sorry I haven't closed it before myself - I forgot.

Simplify build process, and introduce versioning

8578f2f

meeDamian force-pushed the simplify branch from c1a02c4 to 8578f2f Compare August 15, 2019 18:45

moul approved these changes Aug 15, 2019

View reviewed changes

junaruga reviewed Aug 15, 2019

View reviewed changes

junaruga requested changes Aug 15, 2019

View reviewed changes

junaruga mentioned this pull request Aug 16, 2019

Implement tag versioning. #84

Merged

junaruga reviewed Aug 16, 2019

View reviewed changes

meeDamian added 2 commits August 16, 2019 14:23

apply requested changes part 1

893a2b2

change docker creds env vars for travis

f2a8555

meeDamian added 2 commits August 16, 2019 15:07

shebangs reverted

a9f1275

add back travis property

ddc8e09

junaruga closed this Jul 14, 2020



		# Convert Travis-provided repo SLUG to lowercase - Docker's requirement for tags
		SLUG="$(echo "${TRAVIS_REPO_SLUG}" \| tr '[:upper:]' '[:lower:]')"

Simplify & introduce versioning #83

Simplify & introduce versioning #83

Conversation

meeDamian commented Aug 15, 2019

Other changes:

Github deployment

Outcomes

meeDamian commented Aug 15, 2019

junaruga commented Aug 15, 2019

junaruga commented Aug 15, 2019 • edited Loading

junaruga commented Aug 15, 2019 • edited Loading

meeDamian commented Aug 15, 2019

meeDamian commented Aug 15, 2019

moul left a comment

Choose a reason for hiding this comment

junaruga commented Aug 15, 2019 • edited Loading

moul commented Aug 15, 2019

junaruga commented Aug 15, 2019

Image tag version format

Pipeline to rerun already git tagged version

x86_64 prefix

Detail

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

junaruga commented Aug 15, 2019

junaruga left a comment • edited Loading

Choose a reason for hiding this comment

junaruga commented Aug 15, 2019

junaruga commented Aug 16, 2019 • edited Loading

junaruga Aug 16, 2019 • edited Loading

Choose a reason for hiding this comment

meeDamian commented Aug 16, 2019

Image tag version format

meeDamian commented Aug 16, 2019 • edited Loading

Pipeline to rerun already git tagged version

meeDamian commented Aug 16, 2019 • edited Loading

x86_64 prefix

meeDamian commented Aug 16, 2019 • edited Loading

meeDamian commented Aug 16, 2019 • edited Loading

meeDamian commented Aug 16, 2019

junaruga commented Aug 16, 2019

meeDamian commented Aug 16, 2019

junaruga commented Aug 16, 2019 • edited Loading

meeDamian commented Aug 16, 2019

junaruga commented Aug 16, 2019 • edited Loading

junaruga commented Jul 14, 2020

meeDamian commented Jul 16, 2020

junaruga commented Aug 15, 2019 •

edited

Loading

junaruga commented Aug 15, 2019 •

edited

Loading

junaruga commented Aug 15, 2019 •

edited

Loading

junaruga left a comment •

edited

Loading

junaruga commented Aug 16, 2019 •

edited

Loading

junaruga Aug 16, 2019 •

edited

Loading

meeDamian commented Aug 16, 2019 •

edited

Loading

meeDamian commented Aug 16, 2019 •

edited

Loading

meeDamian commented Aug 16, 2019 •

edited

Loading

meeDamian commented Aug 16, 2019 •

edited

Loading

junaruga commented Aug 16, 2019 •

edited

Loading

junaruga commented Aug 16, 2019 •

edited

Loading