Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Improve sbt/gh actions infrastructure #466

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 7 commits into from

Conversation

armanbilge
Copy link
Member

@armanbilge armanbilge commented Aug 10, 2021

WIP more coming :)

Comment on lines +8 to +11
lazy val scala210 = "2.10.7"
lazy val scala211 = "2.11.12"
lazy val scala212 = "2.12.10"
lazy val scala213 = "2.13.1"
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be good to update some of these, I think @sjrd likes to keep them in sync with their respective Scala.js version.

Comment on lines +43 to +55
ThisBuild / githubWorkflowGeneratedCI ~= { jobs =>
var publish = jobs(1)
publish = publish.copy(matrixAdds = Map("scalajs" -> List(scalaJS06, scalaJS1)))
publish = publish.copy(steps = publish.steps.map {
case step: WorkflowStep.Use if step.name.exists(_.startsWith("Download target directories")) =>
step.copy(params = step.params.mapValues(_ + "-${{ matrix.scalajs }}"))
.copy(cond = if (step.name.exists(_.contains(scala210))) Some(s"matrix.scalajs == '${scalaJS06}'") else None)
case step: WorkflowStep.Run if step.name.exists(_.contains(scala210)) =>
step.copy(cond = Some(s"matrix.scalajs == '${scalaJS06}'"))
case step => step
})
jobs.updated(1, publish)
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This whole mess is to cross on 0.6 and 1.0, I look forward to deleting it when we merge into master.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah 0.6 is such a pain this late in the game

@armanbilge armanbilge marked this pull request as ready for review August 10, 2021 06:44
@armanbilge armanbilge changed the title Improve sbt/gh actions infrastucture Improve sbt/gh actions infrastructure Aug 10, 2021
@japgolly
Copy link
Contributor

@armanbilge Just to confirm, this is ready for review and even merge and I believe that because you've assigned me as a reviewer. Is that right, and is that the process we'll follow to know? Sounds like a good idea to me

@armanbilge
Copy link
Member Author

👍 yup that's the process: draft PR is WIP otherwise ready for review and merge with your approval. BTW this will badly conflict with the amazing work you've done in #471, I'm happy for you to merge first and adjust here accordingly.

@japgolly
Copy link
Contributor

Also omg! The gh actions yamls have become monsters!! Plus what used to be making a small change to the yaml is now a bigger change in sbt. Sell me again on why this is better?

@japgolly
Copy link
Contributor

BTW this will badly conflict with the amazing work you've done in #471, I'm happy for you to merge first and adjust here accordingly.

hehe thanks and it's all good. You got in first so I'll update mine if this is merged first

@armanbilge
Copy link
Member Author

Sell me again on why this is better?

Lol!! Yeah this one is a really bad example because of the SJS 0.6/1 cross stuff. It will get better when we can remove that.

The idea is that sbt is the authority on all the Scala versions and any other important settings (projects that need to be cached, etc. etc.). So we don't have to remember to manually keep them in sync with the yaml.

tags-ignore:
- v*
branches: ['**']
tags: [v*]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the inverse of what we want :) Currently it's all tags except v*

Copy link
Member Author

@armanbilge armanbilge Aug 12, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See #466 (comment), I think it's fine like this?

publish:
name: Publish Artifacts
needs: [build]
if: github.event_name != 'pull_request' && (startsWith(github.ref, 'refs/tags/v'))
Copy link
Member Author

@armanbilge armanbilge Aug 12, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually it's fine, this is where the check is whether to publish or not.

@japgolly
Copy link
Contributor

The idea is that sbt is the authority on all the Scala versions and any other important settings (projects that need to be cached, etc. etc.). So we don't have to remember to manually keep them in sync with the yaml.

I'll be honest with you. I hate it. My understanding is that the only shared data between the yamls and sbt is the Scala versions. The disadvantages are that the yamls are huge, overly complicated, hard to read, have to be manually regenerated when we make changes, lock us into assumptions made upstreams (even the setup-scala version), we can't use dependabot to automatically propose action updates as they become available, the already terribly-messy build.sbt now becomes even more messy. All this to share Scala versions? That's my current impression.

In light of all of those concerns, do you still think it's a good idea to go ahead with this? If so, I'd love to hear why (genuinely, not antagonistically) and despite my scepticism I'm totally willing to trust in your judgement and give it a try. It wouldn't be the first time I don't understand the value of something to then come around after being forced to use it for a while :)

@armanbilge
Copy link
Member Author

I'll be honest with you. I hate it.

That's fine, let's dump it! Not gonna lie, it did not come out very nice in this situation. I see what you mean about upstream assumptions, I think I personally appreciate all the machinery it sets up in my own projects (caching, streamlined publishing, etc.). But maybe not appropriate for this project.

@armanbilge armanbilge closed this Aug 12, 2021
@japgolly
Copy link
Contributor

Ok np but only if you genuinely agree. Like I said I'm totally open to giving it a try and seeing how it goes, and I'm honestly hoping to learn of some cool aspect that I'm just not seeing atm. If I'm wrong I want to leeeeeeeeeaaaaaaaaaaaaaaarrrrrrrrrrrnnnnnnnnnn 😄

@armanbilge
Copy link
Member Author

Maybe when we get around to 2.0, I can remake this PR (it will be much nicer!!) and you can see if you like it any better 😁

The disadvantages are that the yamls are huge, overly complicated, hard to read, have to be manually regenerated when we make changes, lock us into assumptions made upstreams

For me, these are what I consider the advantages! I don't think about the yaml anymore, I just appreciate all the machinery that's been installed for me automatically lol!

@japgolly
Copy link
Contributor

japgolly commented Aug 12, 2021

I just appreciate all the machinery that's been installed for me automatically lol!

That's interesting cos I'm looking at all the new sbt config and thinking the same as you are about the yaml haha. Maybe it's just what we're used to. If I was already used to that sbt config and hadn't read up on the gha yml, and you had already been working with the yamls and had never seen the sbt way before, we might be saying the same things but on the opposite sides, haha. But ok cool, we let's reconsider over in 2.x. Thanks for the effort and taking the time to have this discussion with me hey. I'm sorry we're ending up closing this and appreciate the work you did.

@armanbilge armanbilge deleted the topic/sbt-infrastructure branch December 26, 2021 18:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants