Update integration test pack versions

[aeisenberg]

Merge / deployment checklist

• Confirm this change is backwards compatible with existing workflows.
• Confirm the readme has been updated if necessary.
• Confirm the changelog has been updated if necessary.

[adityasharad]

LGTM if tests pass.
Should these always use the latest version? Or is the point that we're testing both explicit versions and implicit latest versions?

[aeisenberg]

Darn...tests still failing. I think I need to create a version 0.0.4 of javascript-all. There must be some dbscheme change that hasn't yet been picked up.

[aeisenberg]

It's still failing. I'm not sure exactly why. I updated both test packs to use the latest javascript-all pack. AFAICT the last change to the semmlecode.javascript.dbscheme file was when I migrated to the lib folder. This change was not in the 2.6.0 release, which the integration tests are currently using, so I still need to investigate why we are getting this error.

[adityasharad]

test-split-workflow is using 2.6.0 and the other three failing tests test-packaging-javascript* are using 2.5.9 (presumably the version in the toolcache). I'm not sure that's the main problem, but as a starting point, perhaps try those tests with tools: latest to force them to use 2.6.0?

[aeisenberg]

I guess it's also possible that the dbscheme of the compiled queries are too new and the upgrade script is not available, so the queries are failing. I'll have to look at this next week.

[aeisenberg]

I forced the failing tests to use the nightly build. Now they are passing.

[edoardopirovano]

As a very temporary fix to unbreak the tests this seems okay, but we definitely need a more permanent solution that doesn't require us to keep manually bumping versions.

[aeisenberg]

I forced the failing tests to use the nightly build. Now they are passing.

In retrospect, this is misleading. I wasn't implying that this is a good solution, or even something I'd like to commit. I'm planning on working on this tomorrow and finding out what is happening, because upgrades should work.

@edoardopirovano as you said, this would only be temporary. If you are being blocked by failing builds, then it is ok to merge. But, I would prefer to explore deeper when I am able to.

[edoardopirovano]

Agree that we should investigate why the upgrades aren't working. I'm not blocked on failing tests, so okay to not merge this and instead wait until we have a proper solution.

[aeisenberg]

The 0.1.0 versions fail because the queries are too new and upgrades are not found. The bug is that we haven't updated codeql resolve upgrades to work with packs yet.

I'll work on this next.

[aeisenberg]

These tests will not be properly fixed until the next release of the CLI. This is because database upgrades is not yet package-aware. I'll fix that shortly, but it won't be available until the release.

[aeisenberg]

Building a new nightly version of the CLI. I expect that once that version is available to the action, then this PR will pass and we can get the action back on track.

[aeisenberg]

This latest version hard-codes the tools bundle being used by the packaging integration tests. This will work for now. However, we need to make sure that the version that is pointed to is not cleaned up by automation.

[aeisenberg]

I made sure that the release is not cleaned up by automation by making it a non-prerelease. Now, it will always show on top of the releases list, which always keeps the 10 latest.