Jx

Q
A

Bug fix?
no

New feature?
no

API breaks?
no

Deprecations?
no

Related tickets
fixes #X, partially #Y, mentioned in #Z

License
Apache 2.0

What's in this PR?

Why?

Additional context

Checklist

[ ] Implementation tested (with at least one cloud provider)
[ ] Error handling code meets the guideline
[ ] Logging code meets the guideline (TODO)
[ ] User guide and development docs updated (if needed)
[ ] Related Helm chart(s) updated (if needed)

To Do

[ ] If the PR is not complete but you want to discuss the approach, list what remains to be done here

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@asdwsda: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

serverless-jenkins
98a9639402eec87782f53196acbf9d8e4cb6b085
link
/test this

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@asdwsda: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

serverless-jenkins
8a1155425fc8e3c737c475d737283f0090be96be
link
/test this

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@asdwsda: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

serverless-jenkins
44b519f357bd18e231fa09ce819c3595cf2c9c4f
link
/test this

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@asdwsda: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

serverless-jenkins
8988282e642465ab6cbc47a50bcabb683ef0b7a9
link
/test this

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@asdwsda: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

serverless-jenkins
1bfdddaba697275c22938f4f7304e6c4c929f796
link
/test this

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@asdwsda: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

serverless-jenkins
4b14109a57010af425993e3800b082b786ab365b
link
/test this

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@asdwsda: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

serverless-jenkins
4b39949a4988fa73c82919d1cc5a4c1bfc3bbef4
link
/test this

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@asdwsda: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

serverless-jenkins
921f05d96e506d68c138d2c0249d7ce26f7b8331
link
/test this

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@asdwsda: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

serverless-jenkins
ace1d90f0cdaa8de07283d744f692875dc4bfbf1
link
/test this

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


Enable Pipelines as code in HACBS workflow

Description

Enable the PAC on HACBS workflow by adding the pipelinesascode annotation in component creation flow.
Type of change

[x] Feature

Screen shots / Gifs for design review

https://user-images.githubusercontent.com/9964343/185442410-bee55725-b1f7-476f-b6be-f3b89b5d9b8c.mov
How to test or reproduce?

Fork a devfile repository eg: https://github.com/devfile-samples/devfile-sample-go-basic
Install this Appstudio staging  GitHub App in your forked repository.
use the forked repository to create component in the UI.

Unit Tests:
Create Utils
    ✓ Should call k8s create util with pipelines-as-code annotations (1 ms)
    ✓ Should not update pipelines-as-code annotations for the existing components without pac annotations (2 ms)
    ✓ Should contain pipelines-as-code annotations for the existing components with pac annotations (1 ms)

Browser conformance:

[x] Chrome
[x] Firefox
[x] Safari
[ ] Edge

cc: @christianvogt

/lgtm
/approve


Retry on YamlException when loading Kubernetes client configuration

I encountered this while running an integration test:

My assumption is that this is caused by a race between writing and ready the Kubernetes client configuration file. By handling the resulting YamlException, we allow the process to be retried.
Microsoft Reviewers: Open in CodeFlow

Done:
// Handle exceptions caused by races between writing and reading the configuration file.
// If the file is loaded while it is still being written, this can result in a YamlException being thrown.
ShouldHandle = new PredicateBuilder().Handle<KubeConfigException>().Handle<YamlException>(),

/backport to release/8.0-preview.5

/backport to release/8.0-preview.5

@joperezr why does the bot not like @ReubenBond ?

/backport to release/8.0-preview5


DRAFT: Changeset execution information properties

Impact

[ ] Bug fix (non-breaking change which fixes expected existing functionality)
[X] Enhancement/New feature (adds functionality without impacting existing logic)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Description

Fixes #5578
This PR adds the ability to reference the following properties in changelogs:

LIQUIBASE_EXECUTION_DEPLOYMENT_ID
LIQUIBASE_EXECUTION_CHANGELOG_FILE
LIQUIBASE_EXECUTION_CHANGESET_ID
LIQUIBASE_EXECUTION_CHANGESET_AUTHOR

Allowing for developers to be able to access the above information  (for example logging liquibase install information).
Things to be aware of

I added two directories to the .gitignore file because they were created when I ran mvn clean install when there was no differences between my branch and the master branch. If this is unwanted, I can easily remove the .gitignore entries... but I figured it made sense to add them. Let me know what to do in this regards.
Things to worry about

Additional Context

Hey @filipelautert! Hope you have been well!
I created this PR in draft because I'd like some help/opinions here. I've got the majority of this working, but can't figure out how to get the correct DEPLOYMENT_ID.
It appears that the properties are all replaced in changelog files before a lock is accquired and the update action is actually run. When the update run is started, accquiring the change lock resets the deployment ID (as explained by this comment.
So my question is... any thoughts on how I could achieve getting the deployment ID so it is available to the changes?
I'm not hard set on the usage of the properties for this... that is just the first thing that came to mind as that substitution is already built in to Liquibase. Not sure if you or your team mates could think of another mechanism that would be better suited?
Thanks!

So my question is... any thoughts on how I could achieve getting the deployment ID so it is available to the changes?

Hey @jasonlyle88 ! Could you provide an example changelog were you would use the deployment id?
But you are right.. we reset the deployment id with each reset. And that's like this because it didn't matter until now as the deployment id is the same for all the operations executed in a single update .
I'm thinking what would be the implications of creating one deployment id and never resetting it, especially for multitenant environments. In this case you would have the same id in different databases.. maybe something else would change? Or maybe flows  would be affected too? Also we can't remove the resets as they are important in multithread environments.
OR maybe it would be easier to parse the deployment id parameter after the code comment  you mentioned .

I suppose we could have a singular deployment ID that does not get reset if we make it more unique. To that end, I did a quick test with the java UUID:
import java.util.UUID;
import java.math.BigInteger;

class UUIDToInt {
    // Shows that the UUID theoretically can span anything from 1 digit to 39 digits
    public static void main(String[] args) {
        UUID uuid;
        String uuidString;
        BigInteger bi;
        String integerString;

        int shortestLength = 99999999;
        int integerLength;

        for (int i = 0; i < 30; i++) {
            uuid = UUID.randomUUID();
            uuidString = uuid.toString().replaceAll( "-" , "" );
            if (i == 0) {
                // Test smallest possible number
                uuidString="00000000000000000000000000000000";
            }
            else if (i == 1) {
                // Test largest possible number
                uuidString="ffffffffffffffffffffffffffffffff";
            }
            bi = new BigInteger( uuidString , 16 );
            integerString = bi.toString() ;
            integerLength = integerString.length();

            if (i > 1 && integerLength < shortestLength) {
                shortestLength = integerLength;
            }

            System.out.println(integerLength + ": " + integerString);
        }

        System.out.println("Shortest generated length: " + shortestLength);
    }
}

This shows that theoretically a generated integer from UUID can be anywhere from 1-39 digits long. Although, practically it will most likely be 36+ digits long from my testing.
If it is acceptable to convert the deployment ID to a UUID string (always 36 characters long, 32 without dashes) or a UUID numeric representation (0-39 characters long), that would allow a single deployment ID to be generated and not need to be regenerated ever since it is unique.
For reference, the deployment ID column is currently a character column of length 10.

One difference in the UUID based number approach that should be noted is that if N values are generated, the Nth + 1 value is not guaranteed to be greater than the Nth value.
Right now, since the DeploymentID is time based, the next generation is always a greater (assuming that it is generated at a different time, which is guaranteed by the database lock)

Hey,
Here is an example of how I was thinking this could be used
<?xml version="1.0" encoding="UTF-8"?>
<databaseChangeLog
    xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:ora="http://www.oracle.com/xml/ns/dbchangelog-ext"
    xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-4.17.xsd"
>
    <changeSet
        id="example"
        author="jlyle"
    >
        <sql endDelimiter="/">
            begin
                -- Do installation stuff
                ...
            exception when others
                --ERROR HANDLER
                logger.log_error(
                    p_text => 'Error with liquibase run',
                    p_additional_info => t_info_tab(
                        t_info_row('Error Code',        sqlcode),
                        t_info_row('Error Message',     sqlerrm),
                        t_info_row('Deployment ID',     '${LIQUIBASE_EXECUTION_DEPLOYMENT_ID}'),
                        t_info_row('Changelog File',    '${LIQUIBASE_EXECUTION_CHANGELOG_FILE}'),
                        t_info_row('Changeset ID',      '${LIQUIBASE_EXECUTION_CHANGESET_ID}'),
                        t_info_row('Changeset Author',  '${LIQUIBASE_EXECUTION_CHANGESET_AUTHOR}')
                    )
                );
            end;
            /
        </sql>
    </changeSet>
</databaseChangeLog>

I agree only having a singular deployment ID could be problematic. Technically, 10 liquibase updates could be executed at almost the same time and end up with the same deployment ID (since it is time based). But only the first one to get the lock executes and the deployment ID is recalculated at that time. This would distinguish each update attempt because its deployment ID time is based on when it got the lock, not when it was executed. Basically, I agree that the resets are important.
I would be interested in how you think the deployment ID could be parsed after the lock is obtained because that would definitely solve the problem. Are you thinking move all parameter replacements to after the database lock is established? Or somehow just doing it for this one special case?

Right, that's the idea! I discussed with some people here and we agreed that if it is possible to move the replacement code inside AbstractUpdateCommandStep it would be great (I'm not sure if it would work). Otherwise keep the parameter replacement where is it, but if it finds LIQUIBASE_EXECUTION_DEPLOYMENT_ID then flag it to be replaced after the last lock is acquired.
What do you think?

I'm absolutely up for either of those items. I haven't dug to much into the AbstractUpdateCommandStep part of things outside knowing its the driver of this. With moving all property replacements, I realize this is a pretty big change. Is that something you or another member want to jump in to handle to make sure there are not any consequences I'm not noticing? Or do you want me to go ahead and attempt it and just report on my attempts?

I tried digging into this... and it requires a lot of knowledge about how everything fits together. I'm a little lost at how I could successfully move the replacement of the properties to AbstractUpdateCommandStep. I would definitely appreciate help here.
Also curious to hear feedback about having a more static deployment ID as I discussed above with the UUID/ numeric version of UUID that does not change with the resets!

Okay... I realized another facet of this last night. Continuing down this path, the replacement of the deployment ID is being done before a checksum is calculated for a changeset. This means that a changeset using this property will always appear as having changed since the changeset would be different because the deployment ID will be different on every execution.
So, it may actually be preferable to replace the deployment ID property (and maybe the other properties I am introducing as well?) later in the process (after the checksums have been calculated and after the lock has been acquired/final deployment ID is generated). Do you agree?
Is there a mechanism in place already to do property replacements later on in the update process?

@filipelautert Okay... sorry for all the pings!
But I think I have a viable solution. Instead of moving the replacement code later in the overall command process (I couldn't see a clean way to do this without A LOT of refactoring), I instead moved the lock acquistion code sooner in the overall command process.
I did this by altering the DbUrlConnectionCommandStep to acquire a changelog lock as soon as a connection to the database is established (and generate a deployment ID so it is available). You'll notice in the DbUrlConnectionCommandStep that I include this lock acquisition for 4 classes.  If there is a better/cleaner way of determining when to acquire the changelog lock and when not to at this step, I'm all for changing this method!
I ran the full test suite and had to update a couple existing tests because of the logic moving around, but overall this seems to be a pretty small change in the grand scheme of things.
Please take a look and let me know if this is viable or not!
I also haven't provided any new tests... want to make sure this process is accepted for trying to write tests (if there are any tests you want me to write...)

And, after sleeping on it, I figured out the command pipeline is controlled by the dependencies listed by the command step class.
When I looked, the UpdateCommandStep class was overriding its parent classes' dependencies (AbstractUpdateCommandStep) and leaving out the LockService class. By switching the UpdateCommandStep to be based on the AbstractUpdateCommandStep classes' dependencies (and therefore including the LockService), this solved the problem other than needing to generate the deployment ID when the LockService.run method was executed.
This is solved the problem of the previous tests I had to change. I was able to change them back, so I am not affecting any commands that I shouldn't be affecting.
I think the only thing left to consider is the fact that anything using the LIQUIBASE_EXECUTION_DEPLOYMENT_ID property will have a different checksum every time it is run. Is this acceptable or not? If this is acceptable... I believe I am ready to take this PR out of DRAFT status and move forward with a full review!

@filipelautert Ah, yup, I'm undoing a good amount of what was done in #4427 .
I'm unfamiliar with fast check, so I will leave that side in your capable hands.
Looking at #5254, I would agree that your hunch is probably correct!
Please let me know if I can be of assistance in any way here!

@filipelautert Any comments on using a UUID type value for the deployment ID?
This would allow me to generate the deployment ID independent of the change log service and it would not need to be reset. Without being reset and with the value being all but guaranteed to be unique, this value can be put somewhere else in the code that is more static (so resetting the changelog service doesn't reset the deployment ID).
Then all my current problems go away, because I can access the deployment ID without any worries of it changing on me.
Thoughts?

This would allow me to generate the deployment ID independent of the change log service and it would not need to be reset. Without being reset and with the value being all but guaranteed to be unique, this value can be put somewhere else in the code that is more static (so resetting the changelog service doesn't reset the deployment ID).

It would mean generating 1 deploymentId as first step right? I think I've a simpler idea that doesn't involve changing dbcl table.
I implemented and merged a fix for the multithreading Scope object here -> https://github.com/liquibase/liquibase/pull/5617/files . So now every thread has it's own scope.
Maybe we could generate a single deploymentId and add it to root scope, and this way we will have only one per liquibase instance .
This would imply:

changing  Scope.getCurrentScope() to define the deploymentId
changing AbstractChangeLogHistoryService.generateDeploymentId() to be a noop method and getDeploymentId() would return Scope value for deploymentId .

Would it resolve your problems?

@filipelautert Very cool. Thats pretty much what I was proposing, you just now have a good logical place for where this should occur! However, I think my question remains about convertin from a time based deployment ID to a UUID based deployment ID. For example, in this new root scope way of doing things, what happens if 2 different systems initialize liquibase within the same second?
Right now, the deployment ID (the final one, the one that gets used) gets calculated after a lock is obtained. This ensures that the deployment IDs are unique because only 1 person can have a lock at a given time.
In your model, wouldn't the deployment ID be calculated based on the start of liquibase, so if two instances are started within a second of eachother, they would end up with the same deployment ID? That was my reasoning for making it a UUID vs the current time based methodology.
Basically, you solved 1 part of the problem, and I still think the UUID solves the other part of the problem.
Thoughts?

Basically, you solved 1 part of the problem, and I still think the UUID solves the other part of the problem.
Thoughts?

I tried to understand why it was created date-based and seems there is no apparent reason for that - which is good as we have other columns to be used to sort it.
Fitting the uuid into the existing 10 characters space would be an easier solution. Changing the size to fit a complete uuid would  involve changes in StandardChangeLogHistoryService.init and would slow down this PR (maybe it could be a second PR only to do this change?) . Anyway I like this idea as uuid are an universal  (pun intended) thing now.

Unfortunately, I don't think its possible to reliably compress/encode down the length of a UUID to 10 characters.
As such, I'm happy to proceed however you think it best. If you want me to create a separate PR to implement the DEPLOYMENT_ID field length change (and also the switch to UUID?), I can do that and put this on hold until that is accepted. Or I can include it in this PR.
Let me know what you and the team think best!

I can do that. I'll get that done sometime soon and when I do I'll pull the PR out or DRAFT status and also work on the secondary PR after that.
Thanks for all your help here!

@filipelautert I have removed this from the draft status. I have manually tested the changes... however, I couldn't figure out how to write tests for this.
Since this has to happen at the time the nodes are parsing (because this is a property which gets replaced during parsing) I essentially need to run a whole changelog that has outputs of the new execution parameters and then have the test look at the output from the run and make sure it contains the correct data. But I couldn't find any examples of how this should be done and could not figure it out myself.
Any help here would be appreciated!

Since this has to happen at the time the nodes are parsing (because this is a property which gets replaced during parsing) I essentially need to run a whole changelog that has outputs of the new execution parameters and then have the test look at the output from the run and make sure it contains the correct data. But I couldn't find any examples of how this should be done and could not figure it out myself.
Any help here would be appreciated!

@jasonlyle88 I believe we would need a new integration test, something like what we have on DiffChangelogIntegrationTest or DiffIntegrationTest inside liquibase-integration-tests. In those tests we are able to run a CommandScope and evaluate the results from the execution so you could validate the 3 parameters used . What do you think? (and sorry for the delay to answer you)

Hey @filipelautert . Thanks for pointing me in the correct direction. I'd never actually looked at the integration tests before, and that makes sense. I've made a first attempt at my integration test, however I can't run the integration test locally and I don't believe I can trigger the integration tests on github.
I've got everything setup, I'm just not sure what the output variable will contain... and therefore unsure what I need to do for my assert.
Would you be able to help/guide me any more? Thanks!

@jasonlyle88 sorry, I missed your last comment.
@MalloD12 could you provide guidance on how to add integration tests here?

Apologies, things got a little busy for a bit, and I'm finally able to get back into some liquibase work.
@MalloD12 , everything you said makes sense.
However... when I came back and started trying to do work, i started running into some issues.
I synced upstream main to my repo and was no longer able to build. I thought maybe I screwed something up, so I cloned a fresh repository and ran mvn clean install (following this guide) and it failed again. So, I thought something with my system got messed up. Since I knew I could run my branch before, I pulled a clean version of my branch, without the latest pull from upstream master, and did an mvn clean install on that... and it worked.
So old code is building just fine for me, but new code won't build, even with 0 modifications from master.
I've tried running mvn clean install on master with Temurin (adoptium) 11, 17, and 21. All fail.
The following is the end of the output from the execution
[INFO]
[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR]   HsqlIntegrationTest>AbstractIntegrationTest.testClearChecksums:843 » CommandExecution liquibase.exception.LiquibaseException: liquibase.exception.MigrationFailedException: Migration failed for changeset changelogs/hsqldb/complete/root.changelog.xml::1.1::nvoxland:
     Reason: liquibase.exception.DatabaseException: object name already exists: SEQ_PERSON in statement [CREATE SEQUENCE PUBLIC.seq_person AS BIGINT] [Failed SQL: (-5504) CREATE SEQUENCE PUBLIC.seq_person AS BIGINT]
[ERROR]   HsqlIntegrationTest>AbstractIntegrationTest.testDbDoc:926 » CommandExecution liquibase.exception.LiquibaseException: liquibase.exception.MigrationFailedException: Migration failed for changeset changelogs/hsqldb/complete/root.changelog.xml::1.1::nvoxland:
     Reason: liquibase.exception.DatabaseException: object name already exists: SEQ_PERSON in statement [CREATE SEQUENCE PUBLIC.seq_person AS BIGINT] [Failed SQL: (-5504) CREATE SEQUENCE PUBLIC.seq_person AS BIGINT]
[ERROR]   HsqlIntegrationTest>AbstractIntegrationTest.testDiff:638->AbstractIntegrationTest.runCompleteChangeLog:356->AbstractIntegrationTest.runChangeLogFile:368 » CommandExecution liquibase.exception.LiquibaseException: liquibase.exception.MigrationFailedException: Migration failed for changeset changelogs/hsqldb/complete/root.changelog.xml::1.1::nvoxland:
     Reason: liquibase.exception.DatabaseException: object name already exists: SEQ_PERSON in statement [CREATE SEQUENCE PUBLIC.seq_person AS BIGINT] [Failed SQL: (-5504) CREATE SEQUENCE PUBLIC.seq_person AS BIGINT]
[ERROR]   HsqlIntegrationTest>AbstractIntegrationTest.testGenerateChangeLogWithNoChanges:1066->AbstractIntegrationTest.runCompleteChangeLog:356->AbstractIntegrationTest.runChangeLogFile:368 » CommandExecution liquibase.exception.LiquibaseException: liquibase.exception.MigrationFailedException: Migration failed for changeset changelogs/hsqldb/complete/root.changelog.xml::1.1::nvoxland:
     Reason: liquibase.exception.DatabaseException: object name already exists: SEQ_PERSON in statement [CREATE SEQUENCE PUBLIC.seq_person AS BIGINT] [Failed SQL: (-5504) CREATE SEQUENCE PUBLIC.seq_person AS BIGINT]
[ERROR]   HsqlIntegrationTest>AbstractIntegrationTest.testRerunDiffChangeLog:660->AbstractIntegrationTest.runCompleteChangeLog:356->AbstractIntegrationTest.runChangeLogFile:368 » CommandExecution liquibase.exception.LiquibaseException: liquibase.exception.MigrationFailedException: Migration failed for changeset changelogs/hsqldb/complete/root.changelog.xml::1.1::nvoxland:
     Reason: liquibase.exception.DatabaseException: object name already exists: SEQ_PERSON in statement [CREATE SEQUENCE PUBLIC.seq_person AS BIGINT] [Failed SQL: (-5504) CREATE SEQUENCE PUBLIC.seq_person AS BIGINT]
[ERROR]   HsqlIntegrationTest>AbstractIntegrationTest.testRollbackToChange:902 » CommandExecution liquibase.exception.LiquibaseException: liquibase.exception.MigrationFailedException: Migration failed for changeset changelogs/hsqldb/rollback/rollbackable.changelog.xml::8a::nvoxland:
     Reason: liquibase.exception.DatabaseException: object name already exists: SEQ_PUBLICATION_ID in statement [CREATE SEQUENCE PUBLIC.seq_publication_id AS BIGINT] [Failed SQL: (-5504) CREATE SEQUENCE PUBLIC.seq_publication_id AS BIGINT]
[ERROR]   HsqlIntegrationTest>AbstractIntegrationTest.testRowCountPrecondition:1145->AbstractIntegrationTest.runChangeLogFile:368 » CommandExecution liquibase.exception.LiquibaseException: liquibase.exception.MigrationFailedException: Migration failed for changeset changelogs/common/common.tests.changelog.xml::seq-test::nvoxland:
     Reason: liquibase.exception.DatabaseException: object name already exists: SEQTESTONALL in statement [CREATE SEQUENCE PUBLIC.seqtestonall AS BIGINT] [Failed SQL: (-5504) CREATE SEQUENCE PUBLIC.seqtestonall AS BIGINT]
[ERROR]   HsqlIntegrationTest>AbstractIntegrationTest.testRunUpdateOnOldChangelogTableFormat:423 » CommandExecution liquibase.exception.LiquibaseException: liquibase.exception.MigrationFailedException: Migration failed for changeset changelogs/hsqldb/complete/root.changelog.xml::1.1::nvoxland:
     Reason: liquibase.exception.DatabaseException: object name already exists: SEQ_PERSON in statement [CREATE SEQUENCE PUBLIC.seq_person AS BIGINT] [Failed SQL: (-5504) CREATE SEQUENCE PUBLIC.seq_person AS BIGINT]
[ERROR]   HsqlIntegrationTest>AbstractIntegrationTest.testSnapshotReportsAllObjectTypes:329->AbstractIntegrationTest.runCompleteChangeLog:356->AbstractIntegrationTest.runChangeLogFile:368 » CommandExecution liquibase.exception.LiquibaseException: liquibase.exception.MigrationFailedException: Migration failed for changeset changelogs/hsqldb/complete/root.changelog.xml::1.1::nvoxland:
     Reason: liquibase.exception.DatabaseException: object name already exists: SEQ_PERSON in statement [CREATE SEQUENCE PUBLIC.seq_person AS BIGINT] [Failed SQL: (-5504) CREATE SEQUENCE PUBLIC.seq_person AS BIGINT]
[ERROR]   HsqlIntegrationTest>AbstractIntegrationTest.testTableExistsPreconditionTableNameMatch:1111->AbstractIntegrationTest.runChangeLogFile:368 » CommandExecution liquibase.exception.LiquibaseException: liquibase.exception.MigrationFailedException: Migration failed for changeset changelogs/common/common.tests.changelog.xml::seq-test::nvoxland:
     Reason: liquibase.exception.DatabaseException: object name already exists: SEQTESTONALL in statement [CREATE SEQUENCE PUBLIC.seqtestonall AS BIGINT] [Failed SQL: (-5504) CREATE SEQUENCE PUBLIC.seqtestonall AS BIGINT]
[ERROR]   HsqlIntegrationTest>AbstractIntegrationTest.testTableIsEmptyPrecondition:1121->AbstractIntegrationTest.runChangeLogFile:368 » CommandExecution liquibase.exception.LiquibaseException: liquibase.exception.MigrationFailedException: Migration failed for changeset changelogs/common/common.tests.changelog.xml::seq-test::nvoxland:
     Reason: liquibase.exception.DatabaseException: object name already exists: SEQTESTONALL in statement [CREATE SEQUENCE PUBLIC.seqtestonall AS BIGINT] [Failed SQL: (-5504) CREATE SEQUENCE PUBLIC.seqtestonall AS BIGINT]
[ERROR]   HsqlIntegrationTest>AbstractIntegrationTest.testTag:628 » CommandExecution liquibase.exception.LiquibaseException: liquibase.exception.MigrationFailedException: Migration failed for changeset changelogs/hsqldb/complete/root.changelog.xml::1.1::nvoxland:
     Reason: liquibase.exception.DatabaseException: object name already exists: SEQ_PERSON in statement [CREATE SEQUENCE PUBLIC.seq_person AS BIGINT] [Failed SQL: (-5504) CREATE SEQUENCE PUBLIC.seq_person AS BIGINT]
[ERROR]   HsqlIntegrationTest>AbstractIntegrationTest.testTagEmptyDatabase:861 » CommandExecution liquibase.exception.LiquibaseException: liquibase.exception.MigrationFailedException: Migration failed for changeset changelogs/hsqldb/rollback/rollbackable.changelog.xml::8a::nvoxland:
     Reason: liquibase.exception.DatabaseException: object name already exists: SEQ_PUBLICATION_ID in statement [CREATE SEQUENCE PUBLIC.seq_publication_id AS BIGINT] [Failed SQL: (-5504) CREATE SEQUENCE PUBLIC.seq_publication_id AS BIGINT]
[ERROR]   HsqlIntegrationTest>AbstractIntegrationTest.testUpdateChangelogChecksum:1201 » CommandExecution liquibase.exception.LiquibaseException: liquibase.exception.MigrationFailedException: Migration failed for changeset changelogs/hsqldb/complete/included.changelog.xml::1.2::nvoxland:
     Reason: liquibase.exception.DatabaseException: object name already exists: SEQ_NEWS in statement [CREATE SEQUENCE PUBLIC.seq_news AS BIGINT] [Failed SQL: (-5504) CREATE SEQUENCE PUBLIC.seq_news AS BIGINT]
[ERROR]   HsqlIntegrationTest>AbstractIntegrationTest.testUpdateClearUpdate:557 » CommandExecution liquibase.exception.LiquibaseException: liquibase.exception.MigrationFailedException: Migration failed for changeset changelogs/hsqldb/complete/root.changelog.xml::1.1::nvoxland:
     Reason: liquibase.exception.DatabaseException: object name already exists: SEQ_PERSON in statement [CREATE SEQUENCE PUBLIC.seq_person AS BIGINT] [Failed SQL: (-5504) CREATE SEQUENCE PUBLIC.seq_person AS BIGINT]
[ERROR]   HsqlIntegrationTest>AbstractIntegrationTest.testUpdateTwice:543 » CommandExecution liquibase.exception.LiquibaseException: liquibase.exception.MigrationFailedException: Migration failed for changeset changelogs/hsqldb/complete/root.changelog.xml::1.1::nvoxland:
     Reason: liquibase.exception.DatabaseException: object name already exists: SEQ_PERSON in statement [CREATE SEQUENCE PUBLIC.seq_person AS BIGINT] [Failed SQL: (-5504) CREATE SEQUENCE PUBLIC.seq_person AS BIGINT]
[INFO]
[ERROR] Tests run: 1137, Failures: 0, Errors: 16, Skipped: 602
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for Liquibase Parent 0-SNAPSHOT:
[INFO]
[INFO] Liquibase Parent ................................... SUCCESS [ 42.811 s]
[INFO] liquibase-standard ................................. SUCCESS [02:00 min]
[INFO] liquibase-cli ...................................... SUCCESS [  9.873 s]
[INFO] liquibase-snowflake ................................ SUCCESS [  9.132 s]
[INFO] Liquibase .......................................... SUCCESS [  1.644 s]
[INFO] liquibase-maven-plugin ............................. SUCCESS [ 21.132 s]
[INFO] liquibase-cdi-jakarta .............................. SUCCESS [ 11.239 s]
[INFO] liquibase-cdi ...................................... SUCCESS [  9.956 s]
[INFO] liquibase-extension-testing ........................ SUCCESS [ 11.557 s]
[INFO] liquibase-integration-tests ........................ FAILURE [01:28 min]
[INFO] liquibase-dist ..................................... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  05:26 min
[INFO] Finished at: 2024-05-02T17:58:29-04:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:3.2.5:test (default-test) on project liquibase-integration-tests:
[ERROR]
[ERROR] Please refer to /Users/jlyle/temp/liquibase/liquibase-integration-tests/target/surefire-reports for the individual test results.
[ERROR] Please refer to dump files (if any exist) [date].dump, [date]-jvmRun[N].dump and [date].dumpstream.
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn <args> -rf :liquibase-integration-tests

I have also attached the associated file from the surefire-reports directory
liquibase.dbtest.hsqldb.HsqlIntegrationTest.txt
@MalloD12 @filipelautert any thoughts on this? Can't really do any development if I can't build/run/test anything 😩

@MalloD12 @filipelautert Some further information:
I deleted the liquibase-integration-tests/src/test/java/liquibase/dbtest/hsqldb/HsqlIntegrationTest.java file that was failing and was able to run mvn clean install without issues. However, I am still not able to test as expected.
Following the setup guide, (specifically the "Running the CLI In Your IDE" section) used to also work fine for me. Now when I attempt to run it, it also fails. Below is the error output:
/Library/Java/JavaVirtualMachines/temurin-21.jdk/Contents/Home/bin/java -javaagent:/Applications/IntelliJ IDEA.app/Contents/lib/idea_rt.jar=53163:/Applications/IntelliJ IDEA.app/Contents/bin -Dfile.encoding=UTF-8 -Dsun.stdout.encoding=UTF-8 -Dsun.stderr.encoding=UTF-8 -classpath /Users/jlyle/Personal/projects/liquibase/liquibase/liquibase-cli/target/classes:/Users/jlyle/Personal/projects/liquibase/liquibase/liquibase-standard/target/classes:/Users/jlyle/.m2/repository/com/opencsv/opencsv/5.9/opencsv-5.9.jar:/Users/jlyle/.m2/repository/org/apache/commons/commons-lang3/3.13.0/commons-lang3-3.13.0.jar:/Users/jlyle/.m2/repository/org/apache/commons/commons-text/1.11.0/commons-text-1.11.0.jar:/Users/jlyle/.m2/repository/org/apache/commons/commons-collections4/4.4/commons-collections4-4.4.jar:/Users/jlyle/.m2/repository/org/yaml/snakeyaml/2.2/snakeyaml-2.2.jar:/Users/jlyle/.m2/repository/javax/xml/bind/jaxb-api/2.3.1/jaxb-api-2.3.1.jar:/Users/jlyle/.m2/repository/info/picocli/picocli/4.7.5/picocli-4.7.5.jar liquibase.integration.commandline.LiquibaseLauncher update
May 02, 2024 8:22:55 PM liquibase.servicelocator
INFO: Cannot load service
java.util.ServiceConfigurationError: liquibase.configuration.AutoloadedConfigurations: Provider com.datical.liquibase.ext.config.ReportConfiguration could not be instantiated
	at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:586)
	at java.base/java.util.ServiceLoader$ProviderImpl.newInstance(ServiceLoader.java:813)
	at java.base/java.util.ServiceLoader$ProviderImpl.get(ServiceLoader.java:729)
	at java.base/java.util.ServiceLoader$3.next(ServiceLoader.java:1403)
	at liquibase.servicelocator.StandardServiceLocator.findInstances(StandardServiceLocator.java:24)
	at liquibase.configuration.LiquibaseConfiguration.init(LiquibaseConfiguration.java:61)
	at liquibase.Scope.getCurrentScope(Scope.java:103)
	at liquibase.command.CommandArgumentDefinition$Building.build(CommandArgumentDefinition.java:299)
	at liquibase.command.core.CalculateChecksumCommandStep.<clinit>(CalculateChecksumCommandStep.java:52)
	at liquibase.integration.commandline.LiquibaseCommandLine.<init>(LiquibaseCommandLine.java:109)
	at liquibase.integration.commandline.LiquibaseCommandLine.main(LiquibaseCommandLine.java:94)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at liquibase.integration.commandline.LiquibaseLauncher.main(LiquibaseLauncher.java:116)
Caused by: java.lang.NoSuchMethodError: 'java.lang.Boolean liquibase.util.ValueHandlerUtil.booleanValueHandler(java.lang.Object)'
	at com.datical.liquibase.ext.config.ReportConfiguration.<clinit>(ReportConfiguration.java:28)
	at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized0(Native Method)
	at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized(Unsafe.java:1160)
	at java.base/jdk.internal.reflect.MethodHandleAccessorFactory.ensureClassInitialized(MethodHandleAccessorFactory.java:300)
	at java.base/jdk.internal.reflect.MethodHandleAccessorFactory.newConstructorAccessor(MethodHandleAccessorFactory.java:103)
	at java.base/jdk.internal.reflect.ReflectionFactory.newConstructorAccessor(ReflectionFactory.java:200)
	at java.base/java.lang.reflect.Constructor.acquireConstructorAccessor(Constructor.java:549)
	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:486)
	at java.base/java.util.ServiceLoader$ProviderImpl.newInstance(ServiceLoader.java:789)
	... 12 more

May 02, 2024 8:22:55 PM liquibase.servicelocator
INFO: Cannot load service
java.util.ServiceConfigurationError: liquibase.configuration.AutoloadedConfigurations: Provider com.datical.liquibase.ext.config.DatabaseChangelogHistoryConfiguration could not be instantiated
	at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:586)
	at java.base/java.util.ServiceLoader$ProviderImpl.newInstance(ServiceLoader.java:813)
	at java.base/java.util.ServiceLoader$ProviderImpl.get(ServiceLoader.java:729)
	at java.base/java.util.ServiceLoader$3.next(ServiceLoader.java:1403)
	at liquibase.servicelocator.StandardServiceLocator.findInstances(StandardServiceLocator.java:24)
	at liquibase.configuration.LiquibaseConfiguration.init(LiquibaseConfiguration.java:61)
	at liquibase.Scope.getCurrentScope(Scope.java:103)
	at liquibase.command.CommandArgumentDefinition$Building.build(CommandArgumentDefinition.java:299)
	at liquibase.command.core.CalculateChecksumCommandStep.<clinit>(CalculateChecksumCommandStep.java:52)
	at liquibase.integration.commandline.LiquibaseCommandLine.<init>(LiquibaseCommandLine.java:109)
	at liquibase.integration.commandline.LiquibaseCommandLine.main(LiquibaseCommandLine.java:94)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at liquibase.integration.commandline.LiquibaseLauncher.main(LiquibaseLauncher.java:116)
Caused by: java.lang.NoSuchMethodError: 'java.lang.Boolean liquibase.util.ValueHandlerUtil.booleanValueHandler(java.lang.Object)'
	at com.datical.liquibase.ext.config.DatabaseChangelogHistoryConfiguration.<clinit>(DatabaseChangelogHistoryConfiguration.java:56)
	at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized0(Native Method)
	at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized(Unsafe.java:1160)
	at java.base/jdk.internal.reflect.MethodHandleAccessorFactory.ensureClassInitialized(MethodHandleAccessorFactory.java:300)
	at java.base/jdk.internal.reflect.MethodHandleAccessorFactory.newConstructorAccessor(MethodHandleAccessorFactory.java:103)
	at java.base/jdk.internal.reflect.ReflectionFactory.newConstructorAccessor(ReflectionFactory.java:200)
	at java.base/java.lang.reflect.Constructor.acquireConstructorAccessor(Constructor.java:549)
	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:486)
	at java.base/java.util.ServiceLoader$ProviderImpl.newInstance(ServiceLoader.java:789)
	... 12 more

May 02, 2024 8:22:56 PM liquibase.servicelocator
INFO: Cannot load service
java.util.ServiceConfigurationError: liquibase.command.CommandStep: Provider com.datical.liquibase.ext.command.helpers.ChecksAutoEnableNewChecksArgument could not be instantiated
	at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:586)
	at java.base/java.util.ServiceLoader$ProviderImpl.newInstance(ServiceLoader.java:813)
	at java.base/java.util.ServiceLoader$ProviderImpl.get(ServiceLoader.java:729)
	at java.base/java.util.ServiceLoader$3.next(ServiceLoader.java:1403)
	at liquibase.servicelocator.StandardServiceLocator.findInstances(StandardServiceLocator.java:24)
	at liquibase.command.CommandFactory.findAllInstances(CommandFactory.java:247)
	at liquibase.command.CommandFactory.getCommands(CommandFactory.java:163)
	at liquibase.integration.commandline.LiquibaseCommandLine.getCommands(LiquibaseCommandLine.java:1112)
	at liquibase.integration.commandline.LiquibaseCommandLine.buildPicoCommandLine(LiquibaseCommandLine.java:210)
	at liquibase.integration.commandline.LiquibaseCommandLine.<init>(LiquibaseCommandLine.java:186)
	at liquibase.integration.commandline.LiquibaseCommandLine.main(LiquibaseCommandLine.java:94)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at liquibase.integration.commandline.LiquibaseLauncher.main(LiquibaseLauncher.java:116)
Caused by: java.lang.NoSuchMethodError: 'java.lang.Boolean liquibase.util.ValueHandlerUtil.booleanValueHandler(java.lang.Object)'
	at com.datical.liquibase.ext.command.helpers.ChecksAutoEnableNewChecksArgument.<clinit>(ChecksAutoEnableNewChecksArgument.java:23)
	at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized0(Native Method)
	at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized(Unsafe.java:1160)
	at java.base/jdk.internal.reflect.MethodHandleAccessorFactory.ensureClassInitialized(MethodHandleAccessorFactory.java:300)
	at java.base/jdk.internal.reflect.MethodHandleAccessorFactory.newConstructorAccessor(MethodHandleAccessorFactory.java:103)
	at java.base/jdk.internal.reflect.ReflectionFactory.newConstructorAccessor(ReflectionFactory.java:200)
	at java.base/java.lang.reflect.Constructor.acquireConstructorAccessor(Constructor.java:549)
	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:486)
	at java.base/java.util.ServiceLoader$ProviderImpl.newInstance(ServiceLoader.java:789)
	... 12 more

May 02, 2024 8:22:56 PM liquibase.servicelocator
INFO: Cannot load service
java.util.ServiceConfigurationError: liquibase.command.CommandStep: Provider com.datical.liquibase.ext.command.checks.ChecksRunCommandStep could not be instantiated
	at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:586)
	at java.base/java.util.ServiceLoader$ProviderImpl.newInstance(ServiceLoader.java:813)
	at java.base/java.util.ServiceLoader$ProviderImpl.get(ServiceLoader.java:729)
	at java.base/java.util.ServiceLoader$3.next(ServiceLoader.java:1403)
	at liquibase.servicelocator.StandardServiceLocator.findInstances(StandardServiceLocator.java:24)
	at liquibase.command.CommandFactory.findAllInstances(CommandFactory.java:247)
	at liquibase.command.CommandFactory.getCommands(CommandFactory.java:163)
	at liquibase.integration.commandline.LiquibaseCommandLine.getCommands(LiquibaseCommandLine.java:1112)
	at liquibase.integration.commandline.LiquibaseCommandLine.buildPicoCommandLine(LiquibaseCommandLine.java:210)
	at liquibase.integration.commandline.LiquibaseCommandLine.<init>(LiquibaseCommandLine.java:186)
	at liquibase.integration.commandline.LiquibaseCommandLine.main(LiquibaseCommandLine.java:94)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at liquibase.integration.commandline.LiquibaseLauncher.main(LiquibaseLauncher.java:116)
Caused by: java.lang.NoSuchMethodError: 'java.lang.Boolean liquibase.util.ValueHandlerUtil.booleanValueHandler(java.lang.Object)'
	at com.datical.liquibase.ext.command.checks.ChecksRunCommandStep.<clinit>(ChecksRunCommandStep.java:211)
	at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized0(Native Method)
	at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized(Unsafe.java:1160)
	at java.base/jdk.internal.reflect.MethodHandleAccessorFactory.ensureClassInitialized(MethodHandleAccessorFactory.java:300)
	at java.base/jdk.internal.reflect.MethodHandleAccessorFactory.newConstructorAccessor(MethodHandleAccessorFactory.java:103)
	at java.base/jdk.internal.reflect.ReflectionFactory.newConstructorAccessor(ReflectionFactory.java:200)
	at java.base/java.lang.reflect.Constructor.acquireConstructorAccessor(Constructor.java:549)
	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:486)
	at java.base/java.util.ServiceLoader$ProviderImpl.newInstance(ServiceLoader.java:789)
	... 12 more

Exception in thread "main" java.lang.reflect.InvocationTargetException
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:118)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at liquibase.integration.commandline.LiquibaseLauncher.main(LiquibaseLauncher.java:116)
Caused by: java.lang.IllegalStateException: Unable to find CommandStep provider for class com.datical.liquibase.ext.command.helpers.ChecksAutoEnableNewChecksArgument
	at liquibase.command.CommandFactory.lambda$whoProvidesClass$4(CommandFactory.java:121)
	at java.base/java.util.Optional.orElseThrow(Optional.java:403)
	at liquibase.command.CommandFactory.whoProvidesClass(CommandFactory.java:121)
	at liquibase.command.CommandFactory.findDependenciesForCommand(CommandFactory.java:104)
	at liquibase.command.CommandFactory.computePipelineForCommandDefinition(CommandFactory.java:77)
	at liquibase.command.CommandFactory.getCommandDefinition(CommandFactory.java:50)
	at liquibase.command.CommandFactory.getCommands(CommandFactory.java:175)
	at liquibase.integration.commandline.LiquibaseCommandLine.getCommands(LiquibaseCommandLine.java:1112)
	at liquibase.integration.commandline.LiquibaseCommandLine.buildPicoCommandLine(LiquibaseCommandLine.java:210)
	at liquibase.integration.commandline.LiquibaseCommandLine.<init>(LiquibaseCommandLine.java:186)
	at liquibase.integration.commandline.LiquibaseCommandLine.main(LiquibaseCommandLine.java:94)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	... 2 more

Process finished with exit code 1

So, I can't do any local testing. I'd love to get back to helping out, so hopefully someone knows what is going on!

Looks like I am running into 2 seperate issues with the mvn clean install failure and the failure to be able to run the CLI through my IDE. I checked out 1 commit on master at a time to determine where things stopped working and each problem can be attributed to a different PR. I have commented on those PRs in relation to the specific problem.
The mvn clean install issue is related to PR #5619
The inability to run the CLI through an IDE issue is related to PR #5729

Looks like I am running into 2 seperate issues with the mvn clean install failure and the failure to be able to run the CLI through my IDE. I checked out 1 commit on master at a time to determine where things stopped working and each problem can be attributed to a different PR. I have commented on those PRs in relation to the specific problem.
The mvn clean install issue is related to PR #5619 The inability to run the CLI through an IDE issue is related to PR #5729

@jasonlyle88 The valuehandler util is a good lead. Seems you version of liquibase-commercial is outdated - this one is donwloaded from github package manager. Could you try to clear it from your m2 cache and build again?

liquibase-integration-tests/src/test/java/liquibase/dbtest/hsqldb/HsqlIntegrationTest.java

@filipelautert I've already tried completely deleting my .m2 directory and it had no effect. However, According to the doc, the LIQUIBASE_HOME should point to a previous version of liquibase. Right now, I am setting that to a Liquibase v4.27.0 build. Could that be the problem? If so, will I need to delete the HSQLDB tests (to get around the other issue I'm having building releases), generate a snapshot artifact, and use that as a home to get IDE testing to work?

The valuehandler util is a good lead. Seems you version of liquibase-commercial is outdated - this one is downloaded from github package manager. Could you try to clear it from your m2 cache and build again?

@filipelautert I've already tried completely deleting my .m2 directory and it had no effect. However, According to the doc, the LIQUIBASE_HOME should point to a previous version of liquibase. Right now, I am setting that to a Liquibase v4.27.0 build. Could that be the problem? If so, will I need to delete the HSQLDB tests (to get around the other issue I'm having building releases), generate a snapshot artifact, and use that as the LIQUIBASE_HOME target to get IDE testing to work?

@jasonlyle88 LIQUIBASE_HOME should not be required to build core. Please remove it and try again, hipefully it will fix your issues. I'll also get that reviewed on our docs side.

@filipelautert Looks like it is required. If I unset the LIQUIBASE_HOME variable, I get the following error:
Exception in thread "main" java.lang.IllegalArgumentException: Unable to find either 'liquibase.home' JVM property nor 'LIQUIBASE_HOME' environment variable
	at liquibase.integration.commandline.LiquibaseLauncher.main(LiquibaseLauncher.java:87)

I am following the setup in the guide, and here is what it looks like for my IDE (IntelliJ IDEA):

Generating a snapshot and then setting that as the LIQUIBASE_HOME seems to solve the issue. I think you were right when you said

liquibase-commercial is outdated - this one is downloaded from github package manager

Usually, using a previous version works just fine, becuase the LIQUIBASE_LAUNCHER_PARENT_CLASSLOADER variable being set to thread allows changed classes to be overridden. However, because code changed that liquibase.integration.commandline.LiquibaseLauncher calls, and that can't be overridden since it is what is being called, it uses liquibase.integration.commandline.LiquibaseLauncher from the old version. Creating a bit of a chicken and egg problem.
Maybe LIQUIBASE_HOME shouldn't be required and the chicken and egg problem can be avoided... but I'm not familiar enough with the launcher and related parts to fully grasp that. So any help would be appreciated!

@filipelautert Found a much more manageable solution than having to generate the snapshot with a mvn install and then finding the artifact in the maven repository, unzipping it somewhere, and setting that to be the LIQUIBASE_HOME. Instead, for the IDE, the LIQUIBASE_HOME can just be set to . so it uses the current executing test. I have only tested this in IntelliJ IDEA, so testing it in a few more IDEs would be idea... but could be a good update for the docs!

@filipelautert Okay, being very chatty, sorry about that. Tried one more thing: setting LIQUIBASE_HOME to a non-existent directory. This also allowed the IDE to run the CLI without issues. So it seems LIQUIBASE_HOME needs to be set... but it doesn't need to be set to anything specific. I assume this would need to be set to something specific if you need special database drivers or custom things included from the lib or internal/lib directories. But I imagine that is a special case. SO, seems like doc just needs to be updated to state that it needs to be set, but only needs to point to a directory that contains lib or internal/lib if files need loaded.
Thoughts?

@filipelautert Okay, being very chatty, sorry about that. Tried one more thing: setting LIQUIBASE_HOME to a non-existent directory. This also allowed the IDE to run the CLI without issues. So it seems LIQUIBASE_HOME needs to be set... but it doesn't need to be set to anything specific. I assume this would need to be set to something specific if you need special database drivers or custom things included from the lib or internal/lib directories. But I imagine that is a special case. SO, seems like doc just needs to be updated to state that it needs to be set, but only needs to point to a directory that contains lib or internal/lib if files need loaded.
Thoughts?

@jasonlyle88 oh right, you are running the launcher. I thought that the problem was with "mvn clean install" . Right, so in this case  you do need LIQUIBASE_HOME.
So my setup is similar to yours, what I change is that I removed liquibase-core from internal/lib to make sure that it uses my code, and I keep an up to date version of liquibase-commercial master-SNAPSHOT in internal/lib so it doesn't yell at me.  Also, as I removed liquibase-core I need to add liquibase-snowflake to internal/lib (or lib) as it will be missed too. I've this setup as I test extensions and other random databases.
Btw, talking about chatty we have discord -> https://discord.gg/pDB5DfE . I'm around there too.

@filipelautert Ha, sorry, yeah, there are two issues. Running mvn clean install still isn't working for me, but the launcher is the issue with running the CLI through the IDE for testing and was related to the ValueHandlerUtil PR.
Good to know about the discord, I'll be joining that shortly!
I'll start taking a look at the integration tests for this actual merge soon as well. Since I have the workaround of deleting the HSQLDB tests for running integrations tests, I should be able to do that without an issue now. Althought I'd still like to get that resolved as it shouldn't need a work around. Thanks for all your help!

@filipelautert After a few detours, I think this is finally all ready with tests and everything! Thanks for all of your help on this one!
@MalloD12 Thanks for all the info on the integration tests. My functionality wasn't specific to postres and I just picked a database at random. I realized the h2 tests were running without any other configuration needed, so I switched the type from postres to h2 and everything just worked instead... so I went with that route!

@filipelautert Okay, being very chatty, sorry about that. Tried one more thing: setting LIQUIBASE_HOME to a non-existent directory. This also allowed the IDE to run the CLI without issues. So it seems LIQUIBASE_HOME needs to be set... but it doesn't need to be set to anything specific. I assume this would need to be set to something specific if you need special database drivers or custom things included from the lib or internal/lib directories. But I imagine that is a special case. SO, seems like doc just needs to be updated to state that it needs to be set, but only needs to point to a directory that contains lib or internal/lib if files need loaded.
Thoughts?

Hi @jasonlyle88,
Sorry for my late reply, I was just following this thread.  LIQUIBASE_HOME should always be set if you are using CLI it would use Liquibase from that directory, now if you use it from a development environment (IDE) as you are doing using LiquibaseLuncher, then its value will be checked to validate whether it's null or "" string.
Similarly to @filipelautert in my working directory I don't have  core and commercial jars in the internal/lib directory.
Regarding testing, something I forgot to mention the other day is when running mvn clean install your liquibase.sdk.local yml file, needs to be set to run the default integration test that is H2, if you try having any other db set there integration test execution will fail, hence your build will do it as well. I only change that value when I want to run integration tests for any other specific DB, but not when building.
Thanks,
Daniel.

@filipelautert Okay, being very chatty, sorry about that. Tried one more thing: setting LIQUIBASE_HOME to a non-existent directory. This also allowed the IDE to run the CLI without issues. So it seems LIQUIBASE_HOME needs to be set... but it doesn't need to be set to anything specific. I assume this would need to be set to something specific if you need special database drivers or custom things included from the lib or internal/lib directories. But I imagine that is a special case. SO, seems like doc just needs to be updated to state that it needs to be set, but only needs to point to a directory that contains lib or internal/lib if files need loaded.
Thoughts?

Hi @jasonlyle88,
Sorry for my late reply, I was just following this thread. LIQUIBASE_HOME should always be set if you are using CLI it would use Liquibase from that directory, now if you use it from a development environment (IDE) as you are doing using LiquibaseLuncher, then its value will be checked to validate whether it's null or "" string.
Similarly to @filipelautert in my working directory I don't have core and commercial jars in the internal/lib directory.
Regarding testing, something I forgot to mention the other day is when running mvn clean install your liquibase.sdk.local yml file, needs to be set to run the default integration test that is H2, if you try having any other db set there integration test execution will fail, hence your build will do it as well. I only change that value when I want to run integration tests for any other specific DB, but not when building.
Thanks, Daniel.

Hey @MalloD12 ,
I don't have a liquibase.sdk.local.yml file. I never have had one, and previously mvn lcean install would work find. But it fails since 5619

@filipelautert Okay, being very chatty, sorry about that. Tried one more thing: setting LIQUIBASE_HOME to a non-existent directory. This also allowed the IDE to run the CLI without issues. So it seems LIQUIBASE_HOME needs to be set... but it doesn't need to be set to anything specific. I assume this would need to be set to something specific if you need special database drivers or custom things included from the lib or internal/lib directories. But I imagine that is a special case. SO, seems like doc just needs to be updated to state that it needs to be set, but only needs to point to a directory that contains lib or internal/lib if files need loaded.
Thoughts?

Hi @jasonlyle88,
Sorry for my late reply, I was just following this thread. LIQUIBASE_HOME should always be set if you are using CLI it would use Liquibase from that directory, now if you use it from a development environment (IDE) as you are doing using LiquibaseLuncher, then its value will be checked to validate whether it's null or "" string.
Similarly to @filipelautert in my working directory I don't have core and commercial jars in the internal/lib directory.
Regarding testing, something I forgot to mention the other day is when running mvn clean install your liquibase.sdk.local yml file, needs to be set to run the default integration test that is H2, if you try having any other db set there integration test execution will fail, hence your build will do it as well. I only change that value when I want to run integration tests for any other specific DB, but not when building.
Thanks, Daniel.

Hey @MalloD12 ,
I don't have a liquibase.sdk.local.yml file. I never have had one, and previously mvn clean install would work find. But it fails since 5619

Ahh ok, that file liquibase.sdk.local.yml is mostly needed when trying to run integration tests locally, if that's not your case you are find without it.

@filipelautert Okay, being very chatty, sorry about that. Tried one more thing: setting LIQUIBASE_HOME to a non-existent directory. This also allowed the IDE to run the CLI without issues. So it seems LIQUIBASE_HOME needs to be set... but it doesn't need to be set to anything specific. I assume this would need to be set to something specific if you need special database drivers or custom things included from the lib or internal/lib directories. But I imagine that is a special case. SO, seems like doc just needs to be updated to state that it needs to be set, but only needs to point to a directory that contains lib or internal/lib if files need loaded.
Thoughts?

Hi @jasonlyle88,
Sorry for my late reply, I was just following this thread. LIQUIBASE_HOME should always be set if you are using CLI it would use Liquibase from that directory, now if you use it from a development environment (IDE) as you are doing using LiquibaseLuncher, then its value will be checked to validate whether it's null or "" string.
Similarly to @filipelautert in my working directory I don't have core and commercial jars in the internal/lib directory.
Regarding testing, something I forgot to mention the other day is when running mvn clean install your liquibase.sdk.local yml file, needs to be set to run the default integration test that is H2, if you try having any other db set there integration test execution will fail, hence your build will do it as well. I only change that value when I want to run integration tests for any other specific DB, but not when building.
Thanks, Daniel.

Hey @MalloD12 ,
I don't have a liquibase.sdk.local.yml file. I never have had one, and previously mvn clean install would work find. But it fails since 5619

Ahh ok, that file liquibase.sdk.local.yml is mostly needed when trying to run integration tests locally, if that's not your case you are find without it.

So this is still an issue. In the docs for how a developer should get started (https://contribute.liquibase.com/code/get-started/env-setup/) it basically says pull the repo and then run mvn clean install. That fails (and is still failing for me) on the hsqldb integration tests. Could be quite the hurdle for new people coming trying to contribute (or even people like me who have been contributing for a while and just aren't super Java literate).

@filipelautert Okay, being very chatty, sorry about that. Tried one more thing: setting LIQUIBASE_HOME to a non-existent directory. This also allowed the IDE to run the CLI without issues. So it seems LIQUIBASE_HOME needs to be set... but it doesn't need to be set to anything specific. I assume this would need to be set to something specific if you need special database drivers or custom things included from the lib or internal/lib directories. But I imagine that is a special case. SO, seems like doc just needs to be updated to state that it needs to be set, but only needs to point to a directory that contains lib or internal/lib if files need loaded.
Thoughts?

Hi @jasonlyle88,
Sorry for my late reply, I was just following this thread. LIQUIBASE_HOME should always be set if you are using CLI it would use Liquibase from that directory, now if you use it from a development environment (IDE) as you are doing using LiquibaseLuncher, then its value will be checked to validate whether it's null or "" string.
Similarly to @filipelautert in my working directory I don't have core and commercial jars in the internal/lib directory.
Regarding testing, something I forgot to mention the other day is when running mvn clean install your liquibase.sdk.local yml file, needs to be set to run the default integration test that is H2, if you try having any other db set there integration test execution will fail, hence your build will do it as well. I only change that value when I want to run integration tests for any other specific DB, but not when building.
Thanks, Daniel.

Hey @MalloD12 ,
I don't have a liquibase.sdk.local.yml file. I never have had one, and previously mvn clean install would work find. But it fails since 5619

Ahh ok, that file liquibase.sdk.local.yml is mostly needed when trying to run integration tests locally, if that's not your case you are find without it.

So this is still an issue. In the docs for how a developer should get started (https://contribute.liquibase.com/code/get-started/env-setup/) it basically says pull the repo and then run mvn clean install. That fails (and is still failing for me) on the hsqldb integration tests. Could be quite the hurdle for new people coming trying to contribute (or even people like me who have been contributing for a while and just aren't super Java literate).

Then, I would recommend that you create a separate issue for that and then we can ask the docs team to prioritize it.
Thanks,
Daniel.

@filipelautert As this is ready for review, would you mind removing the awaiting_response label? Also, do you need anything else from me here to begin this review? I'd love to get this going so I can also get going on its dependent PR #5653

@rberezen Looks like this has been approved for 2 weeks, anything I need to know about as to why it hasn't been merged yet? Just want to make sure I'm not missing anything!

No problem, thank you for everything you all do here!


PHP support for x-codeSamples

Hello,
Would it be possible to include PHP on the supported languages for x-codeSamples syntax highlighting?
I suppose that RapiDoc is using Prism for this. And checking the code, I see that only javascript, markup (html, svg, xml), bash, css, yaml, go, java, json, bash, python, http, csharp, yaml are included.
Is there a way to include Prism language definitions for PHP easily ?
Thank you ! :)

Let me checkout what size difference it makes after including php.
Since RapiDoc is a Web Component we bundle the entire thing in a single package and we are little sensitive to our bundle size

well I tried to include Prism php support, but it breaks our code, I think that was the primary reason for us not to include it.
Here is the issue thats already opened with them https://github.com/PrismJS/prism/issues/2769 (is the same issue preventing us)

well I tried to include Prism php support, but it breaks our code, I think that was the primary reason for us not to include it. Here is the issue thats already opened with them PrismJS/prism#2769 (is the same issue preventing us)

Thank you @mrin9 for trying to include Prism php support again. Let's see if the Prism developers can help to fix the issue.

I'm guessing that docs/prismjs/prism.js is for the website and npm prismjs is for the build, right?

yes docs folder uses the Prism's pre-downloaded code, which we use to build the website and documentation of the product. This works fine and has no connection with npm build. (you may ignore docs folder for this issue)
Our core product is build and bundled using webpack. This is where we get into the issue when we  include php

Our core product is build and bundled using webpack.

I see. I have slight problem with the build: npm run build_windows doesn't generate dist/rapidoc.js. It does generate the minified files, so maybe it's not an issue?

the issue

What issue specifically? A Uncaught TypeError: Cannot read property 'tokenizePlaceholders' of undefined?
Is there an easy way for me to just drop in the generated dist/rapidoc.js or dist/rapidoc-min.js into some project and see whether PHP highlighting works or not?

While RunDevelopment and @mrin9 try to fix this issue... in the meantime I've loaded Prism on my own page and added some dirty javascript/jquery lines that will replace the php <code>  tags on the <rapi-doc> element.
By the way, the method I use to manipulate the content of <rapi-doc>  shadowRoot element may be useful for other things ;)
<link href="prism.css" rel="stylesheet" /> <!--generate .css and .js on https://prismjs.com/download.html -->
<rapi-doc id="the-doc" spec-url="openapi.yaml"></rapi-doc> <!-- RapiDoc element -->
<script type="text/javascript" src="jquery.js"></script> <!-- I'm too lazy to use vanilla js all the time -->
<script type="text/javascript">
// Check event RapiDoc is rendered
document.addEventListener('DOMContentLoaded', (event) =>
{
  let docEl = document.getElementById("the-doc");
  docEl.addEventListener('spec-loaded', (e) => { // RapiDoc will fire this event when everything is rendered
    console.log("RapiDoc rendered");
    // load prism.js once RapiDoc is rendered and, once loaded, start replacing the code tags
    loadScript("prism.js", function() {
      // On each tab with data-tab=php0 inside of the RapiDoc shadowRoot code.
      $(".tab-content[data-tab=php0]", $("#the-doc")[0].shadowRoot).each(function () {
        // Get <code> contents, delete html comments, highlight and update
        var phpcontent = $(this).find("code").text();
        phpcontent = phpcontent.replace(/<\!--.*?-->/g, ""); // remove lit html comments
        phpcontent = Prism.highlight(phpcontent, Prism.languages.php, "php");
        $(this).find("code").html(phpcontent);
      });
    });
  });
});
$( document ).ready(function() {
  loadScript('https://unpkg.com/rapidoc/dist/rapidoc-min.js', function()
  {
    console.log("RapiDoc loaded ");
  });
});
// loadScript is just a function to load a script and execute the callback function
var _arr = {};
var _arr 	= {};
function loadScript(scriptName, callback)
{
  if (!_arr[scriptName]) {
  	_arr[scriptName] = true;
  	var body 		= document.getElementsByTagName('body')[0];
  	var script 		= document.createElement('script');
  	script.type 	= 'text/javascript';
  	script.src 		= scriptName;
  	script.onload = callback;
  	body.appendChild(script);
  } else if (callback) {
  	callback();
  }
}
</script>

Thank you guys.

closing this as its not a bug on RapiDoc's end.


Multiline text not copying

Hey @ryangjchandler
I just stumbled upon the multi line issue:

Any ideas on how you would address this?
Cheers,
Peter

Hi @spekulatius - I'll try to get this reproduce in a CodePen.

Thanks, let me know if you got any questions!
On Sat, 27 Mar 2021 at 15:16, Ryan Chandler @.***>
wrote:

Hi @spekulatius https://github.com/spekulatius - I'll try to get this
reproduce in a CodePen.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ryangjchandler/alpine-clipboard/issues/8#issuecomment-808715406,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACAK7M6ZD7GK4LFPYE37C2TTFW5BPANCNFSM4YDF7G2A
.


fix: cimode localization

PT-1710.
The CIMODE has broken after the last great upgrade.
After fix:

kultus-admin-ui branch is deployed to platta: https://kultus-admin-ui-pr316.dev.hel.ninja :rocket::rocket::rocket:


BinaryView subclasses without init crash

from binaryninja import *
class FooViewUpdateNotification(BinaryDataNotification):
def init(self, view):
self.view = view
class FooView(BinaryView):
name = "Foo"
def __init_(self, data):
    BinaryView.__init__(self, data.file)
    self.notification = FooViewUpdateNotification(self)

@classmethod
def is_valid_for_data(self, data):
    return True

def init(self):
    return True

FooView.register()
This crashes with a NULL dereference.

I just tried this code and failed to repro the NULL dereference. Does this still exist in the lastest build?

Unable to repro, could be fixed.


Stripe plugin should not require secret key

The stripe provider requires the secret key. From stripe docs
We support cross-origin resource sharing, allowing you to interact securely with our API from a client-side web application (though you should never expose your secret API key in any public website's client-side code) (emphasis mine)
I'll have an alternate version up shortly and will link here. Simply put, making the request that requires the sk should be done in the backend...

I agree with you, but users of this library are already depending on it in its current format.  https://github.com/nraboy/ng2-cordova-oauth for Ionic 2 uses the approach that you mentioned since it was a fresh start.

@nraboy : While users are relying on this, it's a huge security risk for them. Any attacker can look into their application's binary and retrieve their Secret key. Once they have that they can charge customers, create transfers, refund all charges, etc.
I would second what @Faeriol said here and strongly recommend that you clearly mention that this plugin/solution is not secure when using Stripe so that no one else implements this in their application today if they come upon your library. One solution could be to display an error or a log when using Stripe directly for example so that developers know about this new version.

Yes I hear what you're saying, but ultimately it is not my job to play cyber nanny on what good or bad things they do in their code.  I would never use an explicit grant type in my app and I can tell you wouldn't either.  Since this library is specifically labeled as an Oauth library, the developer should do their research before trying to use it.
Explicit grant providers (Stripe, etc.) were continuously requested.  If I remove it, people will complain.  If I leave it people will complain.  More than half the providers in this library were contributed by someone else.
This was in no way an attack against you.  I'd like to invite you to add a section to the README that educates people on explicit grant types and which providers are currently of that type.
Best,

I take back some of what I said.
People will complain either way, but it is probably best they complain and be safe.
Please do a PR on the README educating people on explicit grants.  I'd like to invite you to help me change all the explicit grant providers to only return a request token that the user can then use server side for the access token.  Same how it is done in the Ionic 2 library.

@nraboy: First off, I totally understand where you're coming from here really. People asking for this and ultimately they should be aware that this is an issue and not use it or at least make their own informed decision. Unfortunately it can be easy to end up here by googling "Cordova OAuth Stripe" (you're the first result on Google) and not realize the security implications behind this as the repo has multiple providers documented.
I'm not familiar with most of those providers though and I think I've only used Facebook out of those (beyond Stripe obviously). I'd recommend separating the list in the ones that are safe and the ones that aren't with a comment indicating this explicitly
Here's a basic patch to both the README and the comment associated with the Stripe function at least:
0001-Warn-explicitly-that-you-should-not-use-cordovaOauth.txt
It's not great but I feel like people might search for Stripe in the docs and having the comment "in place" would help with the warning being really seen at least.
Hope this helps and thanks for being open about this!

Want to do a PR so you get the credit?

@nraboy If the patch works for you that works for me too. Also there is no emergency in shipping this so if you want to look at other providers and see the ones you also considered deprecated because they have the same security issue and make this in one PR that might make more sense.

It's all done on the development branch so it won't hit the public until it's finished

Sure, just wanted to say that while problematic, it's not an "emergency fix" or anything and didn't want to pressure you into doing this. I just wanted to voice that this is unfortunately a common misunderstanding from users that I deal with often enough at Stripe!

Thanks for this. I understand the situation you are in, and know users are not always easy. I'll open a PR for an updated function which returns the code stripe gives. May I suggest we either:

Replace the insecure call with the new one
Push the new call alongside the new one and specify that the older one is a "legacy, insecure feature" (open on suggestions on how this could be done)

IM SOOOO Sorry... got busy with other stuff...
Here's a copy of a module that only spits out the code we get from stripe.
(function() {
  'use strict';

  angular.module('oauth.stripe', ['oauth.utils'])
    .factory('$ngCordovaStripe', stripe);

  function stripe($q, $http, $cordovaOauthUtility) {
    return { signin: oauthStripe };

    /*
     * Sign into the Stripe service
     *
     * @param    string clientId
     * @param    string clientSecret
     * @param    string appScope
     * @param    object options
     * @return   promise
     */
    function oauthStripe(clientId, clientSecret, appScope, options) {
      var deferred = $q.defer();
      if(window.cordova) {
        if($cordovaOauthUtility.isInAppBrowserInstalled()) {
          var redirect_uri = "http://localhost/callback";
          if(options !== undefined) {
            if(options.hasOwnProperty("redirect_uri")) {
              redirect_uri = options.redirect_uri;
            }
          }
          var browserRef = window.cordova.InAppBrowser.open('https://connect.stripe.com/oauth/authorize?client_id=' + clientId + '&redirect_uri=' + redirect_uri + '&scope=' + appScope + '&response_type=code', '_blank', 'location=no,clearsessioncache=yes,clearcache=yes');
          browserRef.addEventListener('loadstart', function(event) {
            if((event.url).indexOf("http://localhost/callback") === 0) {
              var requestToken = (event.url).split("code=")[1];
              deferred.resolve(requestToken);
              setTimeout(browserRef.close, 5);
            }
          });
          browserRef.addEventListener('exit', function(event) {
            deferred.reject("The sign in flow was canceled");
          });
        } else {
          deferred.reject("Could not find InAppBrowser plugin");
        }
      } else {
        deferred.reject("Cannot authenticate via a web browser");
      }

      return deferred.promise;
    }
  }

  stripe.$inject = ['$q', '$http', '$cordovaOauthUtility'];
})();

Users can use this to obtain a code they can then forward to a backend that will securely manage the API keys

In theory a PR could be opened with this if we agree on the format (which shouldnt be hard to do)


On Apple platforms, __clang_major__ follows a different versioning scheme and version 8 is actually vanilla Clang 3.9, which made the build fail due to __builtin_rotateleft64 not being defined. Extended the condition to check for version 11 instead if the compiler is Apple Clang. Version mapping table on Wikipedia for reference.
Also added an .editorconfig so editors implicitly know to indent with tabs plus a bunch of other good defaults.

... wow. I'll learn to never trust clang major again :) (I thought of using __has_builtin, I guess I'll refactor using that at some point). Thanks!


Fix invalid connection URLs returned by PostgreSQLContainer (#1976)

Reproduced the bug: https://github.com/testcontainers/testcontainers-java/pull/2049/commits/8803fe1f0a389c17be0f8bc6a3c5ed0a18e3de55
Fix #1976 by overriding PostgreSQLContainer#constructUrlForConnection
Needed to cater for an empty String case regardless of the fact that it breaks the method contract:

queryString – query string parameters that should be appended to the JDBC connection URL. The '?' character must be included

because:
https://github.com/testcontainers/testcontainers-java/blob/f1565f1ba842ccfa9d8ed9ee00276f38b7a2546f/modules/jdbc/src/main/java/org/testcontainers/containers/JdbcDatabaseContainer.java#L129

@pivovarit merged 🎉  thank you!

This was released in https://github.com/testcontainers/testcontainers-java/releases/tag/1.14.0 🎉
Thanks for the contribution!


About the inversionTree root

Dear developers,
I think it's better to use the pointer as the root. That is :
from (inversion_tree.go:18)
root  inversionNode
to
root  *inversionNode
from (inversion_tree.go:32)
root: inversionNode{ 	matrix:   identity, 	children: make([]*inversionNode, dataShards+parityShards), },
to
root: &inversionNode{ 	matrix:   identity, 	children: make([]*inversionNode, dataShards+parityShards), },
That improves quite a lot in my tests.
Thanks a lot for any of your reply. I sincerely appreciate it.

@DurantVivado Could you share your tests?
I don't understand how this could give any significant change.

Thanks a lot for replying!😂 Truly appreciation and respect.
In my own testbed
Test File:  erasure_encode_read_test.go
Test Benchmark:  BenchmarkEncodeDecode20x4x24x4096x20Mx2fault

Before Change:

Running tool: /usr/local/go/bin/go test -benchmem -run=^$ -bench ^BenchmarkEncodeDecode20x4x24x4096x20Mx2fault$ github.com/DurantVivado/Grasure -v -cpuprofile profiles/cpu.profile -memprofile profiles/mem.profile -blockprofile profiles/blk.profile -benchtime 10x

goos: linux
goarch: amd64
pkg: github.com/DurantVivado/Grasure
cpu: Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz
BenchmarkEncodeDecode20x4x24x4096x20Mx2fault
BenchmarkEncodeDecode20x4x24x4096x20Mx2fault-2   	      10	 585994617 ns/op	  35.79 MB/s	52339386 B/op	   61678 allocs/op
PASS
ok  	github.com/DurantVivado/Grasure	11.376s

After Change:

Running tool: /usr/local/go/bin/go test -benchmem -run=^$ -bench ^BenchmarkEncodeDecode20x4x24x4096x20Mx2fault$ github.com/DurantVivado/Grasure -v -cpuprofile profiles/cpu.profile -memprofile profiles/mem.profile -blockprofile profiles/blk.profile -benchtime 10x

goos: linux
goarch: amd64
pkg: github.com/DurantVivado/Grasure
cpu: Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz
BenchmarkEncodeDecode20x4x24x4096x20Mx2fault
BenchmarkEncodeDecode20x4x24x4096x20Mx2fault-2   	      10	 281809520 ns/op	  74.42 MB/s	52341989 B/op	   61643 allocs/op
PASS
ok  	github.com/DurantVivado/Grasure	3.363s

The improval is considerably explicit.

@DurantVivado Are you sure this isn't just randomness in the tests? You are reading and writing files which brings much randomness into the benchmark.
I tried running the benchmark, but it fails. Maybe because I use Windows.
BenchmarkReconstructData50x20x1M should test the inversion tree cache, and I see no measurable change, even if changing shards to 1K. In fact, disabling the inversion cache does very little to performance.
So I think your benchmarks is showing something else.
inversionTree is only used as a pointer, and whenever root is accessed it is via pointer methods. So I don't see how it would make any difference whether it is a value or a pointer.

I guess I miss some points somehow. The files I generate is different.
And for tests in BenchmarkReconstructData10x2x10000.  It seems to improve actually not much.(about 10%)

Before

Running tool: /usr/local/go/bin/go test -benchmem -run=^$ -bench ^BenchmarkReconstructData10x2x10000$ github.com/DurantVivado/reedsolomon -v -benchtime=10x

goos: linux
goarch: amd64
pkg: github.com/DurantVivado/reedsolomon
cpu: Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz
BenchmarkReconstructData10x2x10000
BenchmarkReconstructData10x2x10000-2          10              8348 ns/op        14373.84 MB/s       1882 B/op         43 allocs/op
PASS
ok      github.com/DurantVivado/reedsolomon     0.012s

After

Running tool: /usr/local/go/bin/go test -benchmem -run=^$ -bench ^BenchmarkReconstructData10x2x10000$ github.com/DurantVivado/reedsolomon -v -benchtime=10x

goos: linux
goarch: amd64
pkg: github.com/DurantVivado/reedsolomon
cpu: Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz
BenchmarkReconstructData10x2x10000
BenchmarkReconstructData10x2x10000-2          10              7590 ns/op        15810.90 MB/s       1882 B/op         43 allocs/op
PASS
ok      github.com/DurantVivado/reedsolomon     0.015s

I guess I am rookie in go. And need  more practices.😂
Anyway, thanks a lot for your assistance!

With  -benchtime=10x you are basically getting random numbers. Running with default, 1s:
Before, 5 independent runs:
BenchmarkReconstructData10x2x10000-32    	  373849	      3058 ns/op	39240.21 MB/s	     456 B/op	       6 allocs/op
BenchmarkReconstructData10x2x10000-32    	  354892	      3067 ns/op	39131.69 MB/s	     456 B/op	       6 allocs/op
BenchmarkReconstructData10x2x10000-32    	  382095	      3064 ns/op	39159.23 MB/s	     456 B/op	       6 allocs/op
BenchmarkReconstructData10x2x10000-32    	  383332	      3054 ns/op	39294.97 MB/s	     456 B/op	       6 allocs/op
BenchmarkReconstructData10x2x10000-32    	  376168	      3059 ns/op	39223.83 MB/s	     456 B/op	       6 allocs/op

With pointers, 5 runs:
BenchmarkReconstructData10x2x10000-32    	  375007	      3058 ns/op	39239.20 MB/s	     456 B/op	       6 allocs/op
BenchmarkReconstructData10x2x10000-32    	  376861	      3049 ns/op	39354.31 MB/s	     456 B/op	       6 allocs/op
BenchmarkReconstructData10x2x10000-32    	  374106	      3058 ns/op	39240.03 MB/s	     456 B/op	       6 allocs/op
BenchmarkReconstructData10x2x10000-32    	  375428	      3068 ns/op	39112.56 MB/s	     456 B/op	       6 allocs/op
BenchmarkReconstructData10x2x10000-32    	  378624	      3062 ns/op	39193.64 MB/s	     456 B/op	       6 allocs/op

Differences seems to be within run-to-run variance to me.


Renamed uses_xml and uses_action_bar to layout and nav_bar

I added aliases so older code doesn't break, but I like this better. I think I'll be introducing the nav_bar one into ProMotion iOS. Related: https://github.com/clearsightstudio/ProMotion/issues/631#issuecomment-105079694

great call.  This reads more like ruby to me.

I'm a little torn about the nomenclature changes. I see the argument for harmonization with ProMotion iOS, but worry a little a bit about going down the road for having different names for everything. A dev reviewing Android docs is going to be reading a lot about the ActionBar, and will always have to be translating that back to nav_bar when working with BP. If we have too much of that, I think it will be a barrier to adoption. We might like the naming better, but someone familiar at all with the Android API might find it off-putting.
I'm not exactly sure what the alternative is. There might not be a clean solution to this problem. :-/

I actually made the actual method name action_bar for that reason, @darinwilson. It's a fair point. nav_bar is an alias.
I wouldn't want the uses_ prefix, either way.
I'm going to keep working on this and see what makes sense. I think onboarding will happen more often from iOS to Android, rather than vice versa, so it's a consideration. ProMotion is intended to make onboarding easy, and so the API reflects that, rather than strict adherance to the terminology. Even nav_bar in iOS actually refers to a NavigationController instead of a NavigationBar. But since that's what people think of when they want a NavCon, I called it nav_bar. :-)

Yep, that's totally reasonable.
 :)

I love naming things...but then people come in with annoyingly reasonable reasons it won't work. haha!

I'll chime in, I don't like layout here, too broad. Can we do xml_layout or something?

:+1:

I can live with that.


Calculate opened picker position when initializing

This fix is related to issue #1096 . There is no need to calculate the position of the picker when initializing it if it is not opened yet.

This will not address the issue for people using the time picker.
The showTimeInput prop also calls positionCalendar function so that will need to be fixed as well so that it is not called in the prop


Update drive code for angular velocity and offset servo

Code about angular_velocities, offset servo and such should be taken from libhal and the files can be removed on the controls side.

Closing this issue because this is not required for the rover's completion. This can be considered for the future project


picture merging

Hi,
I am quite new to python and tensorflow, but I liked the possibilities of your script, so I tried it. But I cannot find tensorflow 1.4. The earliest version to install seems to be 1.13. And there seem to have been a few changes to the internal code in tf, since 1.4.  When I try to run your merge-code:
$ python tools/process.py \

--input_dir a
--b_dir b
--operation combine
--output_dir c

i get some errors telling me, that there are functions used, that don´t exist in tf 1.13 anymore. I also tried the newer versions up to tf 2.0. Is there a way to install the old versions of tf? Doing this with pip doesn´t work. Or can someone tell me, how to change code, if it isn´t to complex for a newbie?
Here´s the full error-message I get:
WARNING:tensorflow:From E:\Python\Python37\lib\site-packages\tensorflow\python\ops\math_ops.py:3528: setdiff1d (from tensorflow.python.ops.array_ops) is deprecated and will be removed after 2018-11-30.
Instructions for updating:
This op will be removed after the deprecation date. Please switch to tf.sets.difference().
WARNING:tensorflow:From E:\Python\Python37\lib\site-packages\tensorflow\python\ops\control_flow_ops.py:3632: colocate_with (from tensorflow.python.framework.ops) is deprecated and will be removed in a future version.
Instructions for updating:
Colocations handled automatically by placer.
Traceback (most recent call last):
File "tools/process.py", line 306, in
main()
File "tools/process.py", line 242, in main
for src_path in im.find(a.input_dir):
File "C:\Users\Master\pix2pix-tensorflow\tools\tfimage.py", line 115, in find
for filename in os.listdir(d):

I hope you've solved this by now, but if it helps anyone in the future:
Python 3.7 doesn't support Tensorflow GPU, but Python 3.6 does. Creating a virtual environment in conda or the GPU-supported Windows Linux Subsystem should get you up and running. Here's a link with the resolved issue.


Print subarrays with zero sum in cpp.

🚀 Feature
I would like to add the problem printing all the subarray with sum as 0 in cpp.
Have you read the Contributing Guidelines on Pull Requests?
yes
Pitch
I will use hashing to implement this.

/assign


Conditionals notifiers no charts attached

When I use conditional and enable chart in config.yml. But It sent notification without chart. How can I config it?
My config:
settings:
log_level: INFO
update_interval: 300
start_worker_interval: 2
market_data_chunk_size: 1
enable_charts: true
indicators:
candle_recognition:
- enabled: true
alert_enabled: true
alert_frequency: always
signal:
- doji
candle_check: 1
notification: hot
candle_period: 1d
hot: 0
cold: 0
chart: true
If i run without conditional. It send chart
Thanks

Hello @braverynew, chart hasn't been implemented in conditional mode.

Thanks. conditional module working like a charm! waiting for update chart included.

Thanks for your feedback !


Changed hasOwnProperty to [ ]

What was happening

Due to Calculated Columns code, the row are now Proxy and hasOwnProperty hasn't been exposed

What was done

Changed hasOwnProperty to [ ]

Test Steps

Open Save Changes sample
Delete product name in first row and click Save Changes
No error should appear

Checklist

[x] tested locally
[ ] documented the code
[x] clean all warnings and errors of eslint
[ ] requires changes in OutSystems
[ ] requires new sample page in OutSystems

LGTM!


Can bring your own history class

Hello @Frezyx,
I need to monitor my application and keep the log history to do some stuff on it. (Like, to bring back all the logs for our support operations).
So I've moved the logic of your history implementation into a class that I can override like I want.
By the way, I saw that you were thinking about a FileManager implementation, and I think we could use this approach. What do you thinks ?
And by extension, why not offer log history implementations directly with Isar, hive or SQFlite database?
In any case, by passing through a class we'll be free to make our own implementation of the history backup.
EDIT: Sorry, for the previous PR #166, I don't know what happened.
I've added the comments missing from your review.
I'll do another PR, with the Isar implementation and the Readme update. :D

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (9c0cbf6) 100.00% compared to head (f79fe10) 100.00%.
Report is 1 commits behind head on master.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff            @@
##            master      #169   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           10        11    +1
  Lines          175       183    +8
=========================================
+ Hits           175       183    +8

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

Hello @Ppito !
Good history functional extending.
LGMT


Consider adding Enums for the application process

I am worried about the on_message functionality being overridden, as it may potentially block other private conversations with the bot (to be investigated).
Some mechanism must be in place for the bot to recognize what is currently happening in private chats with members. Perhaps sessions? Upon starting application a new application session is entered - each dm is treated as an application-related thing. After quitting and doing something else, some other session is created and new functionality is used. While all this happens, general commands will still work and be handled correctly.
With that in mind, on_message should probably live in bot.py instead of apply.py.

It seems so far that there has not been a need to change the current code, so I am closing this issue - it can be reopened in the future if needed.


Fix to swipe background color changes

Before this fix, it a swipeBackgoundColor was set and then reset, it wouldn't update the swipe background color.
This adds support for the case in which a background is set and then needs to be changed without re-initializing the cell.

Thanks


Use juju secrets for Kubeflow secret information like DB-root-password, minio-keys

Starting juju 3.0 there are secrets introduced.
Secrets currently are put separately for every application. It would be nice to use the juju secrets mechanism and secure them better.

@Barteus can you elaborate what you'd like achieved a little more?  I could see this going a few different ways.  Are any of these what you were thinking?

make it better for an operator (say mlflow) to get credentials from another operator (say minio)
make it better for an operator (say mlflow or kfp) to pass credentials for something a user would need (say minio) to the user (in a notebook or a pipeline)

If I understand the first iteration of Juju secrets correctly, it will provide a more secure way of passing sensitive information between operators (instead of passing via relations, we can pass via secrets), but it will not help a charm pass sensitive data to kubernetes or a workload.

It has been a few months since the last comment.
Let's start with what we get from Juju's secrets. It would be awesome if we could avoid exchanging information between operators in the open text.
The question remains: how do operators/charms persist the secrets in Kubernetes?


[Event-Request] table 1670 "Option Lookup Buffer" - OnBeforeIncludeOption

Hi,
is it possible, that the existing Publisher "OnBeforeIncludeOption" is extended with the Document Type?
At this Point it is only for Sales or Purchase in general, but it would be very nice if we can differ the options by document type.
Thanks in advice

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.