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
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