Nevermind. I learned that workflows don't run if your branch has conflicts with the branch it will merge into.
On Sun, Mar 24, 2024 at 1:18 AM Mike Beckerle <mbecke...@apache.org> wrote: > The push to this branch on my fork usually causes our workflows that test > it on all those configurations, to run. > > Nothing running though. It says no workflows. > > Anybody have a clue why? > > On Sun, Mar 24, 2024 at 12:24 AM Mike Beckerle <notificati...@github.com> > wrote: > >> *@mbeckerle* commented on this pull request. >> >> Latest update resolves all issues I know of. >> @olabusayoT <https://github.com/olabusayoT> @tuxji >> <https://github.com/tuxji> or others, I need additional review. >> There are many changes here, but most are uninteresting. The thing to do >> is look at the layers in daffodil-runtime1-layers >> <https://issues.apache.org/jira/browse/DAFFODIL-runtime1-layers>, and >> the tests of those in daffodil-core >> <https://issues.apache.org/jira/browse/DAFFODIL-core>/src/test/.../layers >> and daffodil-test >> <https://issues.apache.org/jira/browse/DAFFODIL-test>/src/test/.... >> layers. Then the implementation in daffodil-runtime1 >> <https://issues.apache.org/jira/browse/DAFFODIL-runtime1> >> /src/main/...layers. >> >> I think there should be good test coverage now also. As I added a bunch >> of tests to exercise the error paths. >> ------------------------------ >> >> In >> daffodil-runtime1-layers/src/main/scala/org/apache/daffodil/layers/runtime1/BoundaryMarkLayer.scala >> <https://github.com/apache/daffodil/pull/1187#discussion_r1536734445>: >> >> > + * the data stream on unparsing. >> + * @param layerEncoding a string which is the name of the character set >> encoding used to >> + * decode characters during the search for the >> boundary mark, and used >> + * to encode characters when inserting the boundary >> mark when unparsing. >> + */ >> + private[layers] def setLayerVariableParameters( >> + boundaryMark: String, >> + layerEncoding: String, >> + ): Unit = { >> + this.boundaryMark = boundaryMark >> + if (boundaryMark.isEmpty) >> + processingError("The boundaryMark variable value may not be empty >> string.") >> + if (boundaryMark.length > maxBoundaryMarkLength) >> + processingError( >> + s"The boundaryMark string length may not be greater than the limit: >> $maxBoundaryMarkLength", >> + ) >> >> Latest commit the approach to this has changed. All exceptions are by >> default fatal, but a call to setProcessingErrorException can be used to >> mark an exception (or runtime exception) to be converted into a parse error. >> >> — >> Reply to this email directly, view it on GitHub >> <https://github.com/apache/daffodil/pull/1187#pullrequestreview-1956471656>, >> or unsubscribe >> <https://github.com/notifications/unsubscribe-auth/AALUDA5TKUBOBHJEDB7RK2LYZZIOXAVCNFSM6AAAAABEZV4WB6VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTSNJWGQ3TCNRVGY> >> . >> You are receiving this because you are subscribed to this thread.Message >> ID: <apache/daffodil/pull/1187/review/1956471...@github.com> >> >
