Yeah that would work. Weasel would show up as a separate checkmark or "X", so it would be easier to tell when weasel failed or not. If a single check fails, we get the "X", so it would be hard to miss.
-Zach On Mon, Jun 29, 2020 at 12:49 PM ocket 8888 <[email protected]> wrote: > Alternatively it's trivial to run weasel in a GH Action, which would be > totally independent of whatever's happening in Jenkins. > > On Mon, Jun 29, 2020 at 10:24 AM Zach Hoffman <[email protected]> wrote: > > > Hey ATC, > > > > Can we change the CI jobs ( > > https://builds.apache.org/search/?q=trafficcontrol) to run weasel after > > the > > other containers exit? > > > > When running against https://github.com/apache/trafficcontrol/pull/4758 > , > > weasel fails because it references files that existed when it started but > > had since been deleted. Example (search for panic: Failed when > enumerating > > working directory): > > https://builds.apache.org/job/trafficcontrol-PR/6173/consoleText > > > > After speaking to the author of comcast/weasel (alficles), it sounds like > > the problem exists in golang's filesystem walker itself, so a fix would > > involve rewriting that library and would be easier to just avoid. To > avoid > > the issue, the non-weasel containers would run before weasel to avoid the > > filesystem changing while weasel runs. > > > > Is this doable? The PR job seems to consistently fail for > > https://builds.apache.org/job/trafficcontrol-PR/6173/consoleText ,so it > > should not be merged until the CI jobs are changed to accommodate weasel. > > > > -Zach > > >
