Replace remaining third party actions with native Github CLI commands + Implement idea from #233 + Automate Kron4ek wine builds pulling + Various improvements

[koplo199]

• Replace remaining third party actions with native Github CLI commands
• Fixes Improved naming of new component updates? #233
• Automate Kron4ek wine builds pulling
• Various improvements (dependencies caching, etc)

[Arcitec]

This is awesome and will be a huge help for managing bottle components! Bottles is blessed to have you on the team! :)

if [ "$channel" = "unstable" ] && [ "$latest_channel" = "unstable" ]; then
    if [[ $latest =~ .*-([[:digit:]])-[[:alnum:]]{7} ]]; then
        revision="${BASH_REMATCH[1]}"
        commit_sha=${component_name: -7}
        ((updated_revision=$revision+1))
        component_name=${component_name/-$revision-$commit_sha/-$updated_revision-$commit_sha}
        echo "NAME=$component_name" >> $GITHUB_ENV
    fi
fi

This keeps rolling forever, right?

So the revisions would look like this:

dxvk-2.0-1-12901b5
dxvk-2.0-2-18b0ef6
dxvk-2.0-3-196fefe
dxvk-2.0-4-7644776
dxvk-2.0-5-c55c093
dxvk-2.0-6-d020f44
dxvk-2.1-7 (the latest "stable")
dxvk-2.1-8-fe37bc2 (first git revision/commit after 2.1)
dxvk-2.2-9 (the next "stable")

It won't really matter but is there a way to handle restarting the sequence whenever the upstream project changes their latest project tag? Meaning we restart counting revisions at 1 whenever the most recent tag changes upstream.

Edit: Upon closer look, it seems like maybe earlier parts of the code are handling the initial setting of the dxvk-2.1 for stable, and the dxvk-2.1-1-fe37bc2 (first "unstable/git build") and that the revision increment only happens within the later builds of that tagged version. But I don't see how that part of the code works, so I'll ask just in case. :D

[koplo199]

This is awesome and will be a huge help for managing bottle components! Bottles is blessed to have you on the team! :)

I'm not on the team, I just like to contribute to Bottles but thank you ^^

Edit: Upon closer look, it seems like maybe earlier parts of the code are handling the initial setting of the dxvk-2.1 for stable, and the dxvk-2.1-1-fe37bc2 (first "unstable/git build") and that the revision increment only happens within the later builds of that tagged version.

This is exactly what is happening :) First, there is an environment variable which set the component name following the stable naming scheme:

components/.github/workflows/pull-components.yml

Line 103 in 99e3f51

lowercase_component_name=$(echo "${{ matrix.components.name-prefix }}${{ steps.check-release.outputs.version }}" | tr "[:upper:]" "[:lower:]")

(with dxvk- being the name-prefix, and 2.1 the pulled version tag, eventually the name is also transformed to lowercase)

If a stable update is found, then check for experimental/unstable builds are ignored. If not, the environment variable is updated with the experimental naming scheme:

components/.github/workflows/pull-components.yml

Line 156 in 99e3f51

lowercase_component_name=$(echo "${{ matrix.components.name-prefix }}${{ steps.check-release.outputs.version }}-1-${commit_sha1::7}" | tr "[:upper:]" "[:lower:]")

But I don't see how that part of the code works, so I'll ask just in case. :D

Well, hopefully you did because it allowed me to see and fix a mistake, the line:

component_name=${component_name/-$revision-$commit_sha/-$updated_revision-$commit_sha}

Should be in fact:

component_name=${component_name/-1-$commit_sha/-$updated_revision-$commit_sha}

;)

[Arcitec]

Oh! Thanks for the explanation, and nice catch about the -1- pattern!

Edit: I incorrectly thought there was an error in the new code, but realized now that the component_name is probably always component_name=dxvk-2.1-1-<new_commit_sha>? In that case your new replacement pattern makes sense and I wasted some time here, sorry about that. I don't know how your build system works. :)

It seems to be doing exactly that pattern in the code you quoted for "unstable builds". So the naming seems to be <component>-<version tag>-1-<newest git commit hash>:

lowercase_component_name=$(echo "${{ matrix.components.name-prefix }}${{ steps.check-release.outputs.version }}-1-${commit_sha1::7}" | tr "[:upper:]" "[:lower:]")

In that case your new code is definitely correct. Awesome. :)

[Arcitec]

Btw, what happens in this scenario?

$latest=dxvk-2.1-5-82f23e
$component_name=dxvk-2.2-1-f62be4

I think then it would name the first version of dxvk-2.2 as revision -6-. Would that scenario ever be able to happen?

Whether it breaks or not depends on whether Bottles is guaranteed to always make a dxvk-2.2 (no suffix) first and ignoring the latest git commit, every time there is a new tag in an upstream project. Then it will work, since we'll keep our pull_components -1-<commit> name in that scenario.

[koplo199]

Whether it breaks or not depends on whether Bottles is guaranteed to always make a dxvk-2.2 (no suffix) first and ignoring the latest git commit, every time there is a new tag in an upstream project.

Yes, this is what happens: if a stable update is detected, then the CI does not check for unstable builds (which makes sense).

Concretely this is achieved using the UPDATED variable:

components/.github/workflows/pull-components.yml

Lines 114 to 118 in 99e3f51

	- name: Update stable input_file entry
	working-directory: "bottle-components-repository"
	run: |
	# This script can set env.UPDATED to true
	./input_files/update_yml_entries.sh

Which is then checked later in the workflow at multiple occasions, for instance when deciding whether to check or not for experimental builds:

components/.github/workflows/pull-components.yml

Lines 139 to 141 in 99e3f51

	- name: Check for new artifact
	id: download-artifact
	if: matrix.components.workflow != '' && env.UPDATED != 'true'

That way, the scenario you described in your last comment is guaranteed to never happen.

[Arcitec]

@koplo199 Perfect perfect. One more potential pitfall to ask about: When the CI names the first "git revision" (dxvk-2.2-1-f62be4), does it get instantly renamed to dxvk-2.2-2-f62be4? Probably not, since $latest would be dxvk-2.2 I think, so it wouldn't increment $revision yet. Just checking. If that works too then everything really looks good to merge. :)

[jntesteves]

I'm not on the team either, but I feel this PR is a bit overloaded. There are two independent things going on here, the improvements to CI, and then the addition of the Kron4ek builds. My comments above only refer to the last commit: Automate Kron4ek wine builds pulling

[koplo199]

I'm not on the team either, but I feel this PR is a bit overloaded. There are two independent things going on here, the improvements to CI, and then the addition of the Kron4ek builds. My comments above only refer to the last commit: Automate Kron4ek wine builds pulling

It feels overloaded because it probably is. But it's too late now ¯\(ツ)/¯

[Kinsteen]

Hi @koplo199 ! Is this ready to be merged, as #227 is merged now?

Edit: I've left a small comment about dummy/.gitkeep

[koplo199]

@Kinsteen Rebase done, it's ready for merge now (it includes the .gitkeep change) 👌