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

Update test-sverchok.yml #4141

Merged
merged 77 commits into from
Jun 6, 2021
Merged

Update test-sverchok.yml #4141

merged 77 commits into from
Jun 6, 2021

Conversation

zeffii
Copy link
Collaborator

@zeffii zeffii commented Jun 3, 2021

testing yaml blindly. eat me.

ok a few notes then.. for the bash leppers such as myself :)

basename from an archive

BLENDER_URL=https://ftp.nluug.nl/pub/graphics/blender/release/Blender2.93/blender-2.93.0-linux-x64.tar.xz
BLENDER_DIR=$(basename $BLENDER_URL .tar.xz)
echo $BLENDER_DIR
#  blender-2.93.0-linux-x64

this is the equivalent to python

BLENDER_URL = "https://ftp.nluug.nl/pub/graphics/blender/release/Blender2.93/blender-2.93.0-linux-x64.tar.xz"
BLENDER_DIR = os.path.basename(BLENDER_URL).replace(".tar.xz", "")
print(BLENDER_DIR)
>>>  "blender-2.93.0-linux-x64"

@zeffii
Copy link
Collaborator Author

zeffii commented Jun 3, 2021

@portnov i have movement.

image

we probably don't want to hardcode blender-2.93.0-linux-x64 anywhere, so how does one rename
installation/blender/blender-2.93.0-linux-x64 to installation/blender/blender

something like ?

mv "installation/blender/" + ${BLENDER_DIR} installation/blender/blender
or
mv "installation/blender/${BLENDER_DIR}" installation/blender/blender
or
... ?

i don't know how to mix literals with strings.

@portnov
Copy link
Collaborator

portnov commented Jun 3, 2021

@zeffii $VARIABLE (or ${VARIABLE}, which is the same) is just replaced with value of VARIABLE. You can think about it in terms of python's f-strings.
Python:

print(f"Hello {variable}")

Shell:

echo Hello $variable

The difference is, in shell you do not have any special "context markers" for f-strings (like f""), everything in shell is one big f-string :)

so,
Python

move(f"dir1/{BLENDER_DIR}/blender", f"dir2/{BLENDER_DIR}/blender")

Shell

mv dir1/$BLENDER_DIR/blender dir2/$BLENDER_DIR/blender

@zeffii
Copy link
Collaborator Author

zeffii commented Jun 5, 2021

@portnov @vicdoval why is the newly downloaded blender/python dependancies gone when this job is triggered again?

that caching is a little beyond my ability to figure out,.. unless ofcourse i start throwing all kinds of mad stuff at the actions until something clicks. but maybe someone knows.

https://docs.github.com/en/actions/guides/caching-dependencies-to-speed-up-workflows

i'll keep poking at it :)

@zeffii
Copy link
Collaborator Author

zeffii commented Jun 5, 2021

we make some kind of a key file using md5sum blender

@portnov
Copy link
Collaborator

portnov commented Jun 5, 2021

Maybe you should change cache key? For example, "empty" -> "b29"

@Minoru
Copy link

Minoru commented Jun 5, 2021

Hi! Portnov shared a link to this PR, so I took a peek.

The main problem here is that the cache key doesn't depend on anything, it's a fixed value. So you're using the cache that you created some time ago, and GitHub doesn't update it because the key at the end of the run is the same as at the start of the run.

You can fix this temporarily by changing the key as @portnov suggested, but you'll have to do it every time you change anything about Blender installation (e.g. Blender version or release).

A better approach would be to include Blender version in the key, something like this:

jobs:
  build:
    env:
      blender_version: "2.93"
    steps:
      - uses: actions/cache@v2
        with:
          path: ./installation
          key: blender-${{ env.blender_version }}

Now every time you change blender_version, the key will change, and the job will start without a cache. At the end of the job, GitHub will pack up ./installation and use it in all future jobs until you change blender_version again.

The cache can even depend on the workflow file itself: key: blender-${{ env.blender_version }}-${{ hashFiles('.github/workflows/test-sverchok.yml') }}. That way, when you change your Blender installation script, the cache key changes too, and GitHub is forced to create a new cache file.

Hope this helps.

@Minoru
Copy link

Minoru commented Jun 5, 2021

Ah, and you don't need to manually add a "post cache" step, GitHub updates the cache automatically at the end of each run (if the key changed).

@zeffii
Copy link
Collaborator Author

zeffii commented Jun 5, 2021

@Minoru that is very helpful! the syntax is new to me, but i'll have time tomorrow to complete this. if someone else doesn't do it already.

@Minoru
Copy link

Minoru commented Jun 5, 2021

You're welcome! ae3a434 and cae2c43 don't work because the blender_version is supposed to be under env — it's an environment variable ;)

@zeffii
Copy link
Collaborator Author

zeffii commented Jun 5, 2021

i still have no idea what i'm doing. but this is progress.

@zeffii zeffii merged commit ef0df90 into master Jun 6, 2021
@zeffii
Copy link
Collaborator Author

zeffii commented Jun 6, 2021

thank you for your time @Minoru ! works as hoped !

@zeffii
Copy link
Collaborator Author

zeffii commented Jun 6, 2021

i'll keep poking around in this, and document it.

@zeffii zeffii deleted the zeffii-patch-1 branch June 10, 2021 13:06
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 this pull request may close these issues.

3 participants