ok fixed up the new blocker issues that cropped up over the week

cutting 1.10.756 now

Cool... https://clojure.atlassian.net/projects/CLJS/issues/CLJS-3245 is a cut-n-dry one we could apply in order to get unit tests running again

fixed, building 1.10.758

@alexmiller another vote for just hooking in @mfikes CI stuff into the ClojureScript main repo so I can see if a commit is failing test

around releases this really like flying blind - manually running everything locally is not practical

it's too easy to forget something

other option would be to do it Jenkins but this seems like a fairly large task for you

would be happy to learn more about what this would mean

are you talking about tests in the clojurescript build itself or something external?

I can make a test job to do arbitrary bash whatever

ClojureScript has TravisCI and AppVeyor "metadata" files in the root of its tree. For TravisCI, it is pretty much just "go in and turn it on", I think.

it sounds like you want "when there are commits on clojurescript, then run thing and report" and that's not hard structurally, but depends what "thing" requires

can you point me more precisely?

oh, .travis.yml

Yeah, in Travis, minimally it really is just a switch ^

Of course, you can mess around with more complicated settings down in there, but fundamentally, it just starts listening to GitHub commits and puts green checkmarks or red Xs in GitHub, and mails people.

the travis one seems like it could pretty trivially be just a bash script, which I could easily embed in a jenkins job

I think it can do that connection back to gh too, but I haven't done that part before

the appveyor one is windows?

looks like there are jenkins plugins that can actually run travis yml directly

hrm, looks out of date

yes just all of the tests in ClojureScript itself would be great, nothing external

your last build failed btw, complaining about upload staging rules which seems very strange to me

"upload staging rules"?

oh kicked it again

when you upload a package of artifacts to maven, it applie some staging rules to check that pom has certain attributes, stuff is signed, yada yada

afaik, nothing should have changed though in what you're making or what the rules are

well if it fails again, I'll look deeper

@alexmiller hrm, failed again

the rule looks like it's failing because that version already exists

which it does

https://repo1.maven.org/maven2/org/clojure/clojurescript/1.10.758/

do you need to bump that or something?

oh hrm, not sure what happened ok, then we're ok - the version number is automatically computed

looks like it was built and released at 6:15 am today (not sure if that's my time or eastern), then failed in a rebuild at 8:35 am, and just now

I don't know - I'd double-check that your last changes are in there

it's a little unclear to me what happened there

I'll look at the test stuff this afternoon

Canary and (mfikes) CI are all green now (current master) https://github.com/cljs-oss/canary https://github.com/mfikes/clojurescript/commits/master

@alexmiller huh it appears something did go wrong, I wasn't hallucinating

https://github.com/clojure/clojurescript/releases

758 never appeared under GitHub releases

so it seems weird that Jenkins said it happened but the tag was never created

looking at it again it looks like the part that waits for central to release timed out and so the build job failed and wasn't tagged

but I bet the release did actually happen to maven, just after the timeout

and then the next build failed because the release was already theree

so I would touch something so the rev is different and rebuild

I missed the timeout message when I looked before

@alexmiller or I could just create the tag myself no?

(to go avoid going through all the steps when they're really not needed)

that too

k

@alexmiller website could use a bump whenever you get a chance