fthomas on simplify-ProcessAlg
Simplify ProcessAlg This simpl… (compare)
fthomas on main
Update Scala version to 3.2.2 Merge pull request #2950 from K… (compare)
fthomas on bsp
Rename function to create an Ex… (compare)
fthomas on bsp
Handle artifactIds with cross b… (compare)
mill-plugin
sbt project to mill-plugin_0.9
and mill-plugin_0.10
and changing this line https://github.com/scala-steward-org/scala-steward/blob/main/modules/core/src/main/scala/org/scalasteward/core/buildtool/mill/MillAlg.scala#L77 would be enough
afternoon all, been poking around a bit but couldn't find an answer to it so apologies if i've just missed it. i'm running a local copy of scala-steward periodically on AWS Codebuild against a range of private projects, all of these projects depend on one or more other libraries, problem being is that these libraries are deployed to an internal artifactory only accessible behind a certificate. normally we can just provide these certs via SBT_OPTS and a local run of sbt can find it just fine.
however, even with running scala-steward in TRACE mode and ensuring the correct SBT_OPTS are being passed through, i can't see a reference to these private dependencies nor any PR's raised for these dependencies anywhere, am i just missing something obvious here?
thanks
I seem to be having an odd issue with scala-steward. I have just integrated it with an open source project and I am getting pull requests as you can see here aiven/guardian-for-apache-kafka#115 however it seems that any PR's created by scala-steward are failing github action's CI runs
I think the issue is that for some reason, githuba actions triggered by PR's created specifically by scala-steward don't seem to have access to secrets stored in environment variables (see https://github.com/aiven/guardian-for-apache-kafka/blob/main/.github/workflows/ci.yml#L17-L22)
I think github recently got a button to rebase a PR (without merging it in). If not and you have Mergify you can command it with a comment
Unfortunately I cannot do this because we have a rule on repository to only allow signed commits and rebasing someone else's PR removes the signing of the commit
I will see if closing and reopening the PR will work but there are going to be merge conflicts unless the branch that scala-steward created gets updated
Hi Scala Steward team,
I'm looking at developing a version of Scala Steward that is run on a local repo and will create the PR with updates.
The use case that's motivating this is to solve the problem when an organisation doesn't want to use the
community Scala Steward and doesn't have the capacity or resources to run a self hosted version.
Is this something that a contribution that would be accepted?
#!/bin/sh
export STEWARD_DIR=~/sandbox/scala-steward
export LOGIN="xxx"
export EMAIL="xxx"
docker run -v $STEWARD_DIR:/opt/scala-steward -it fthomas/scala-steward:latest \
--workspace "/opt/scala-steward/workspace" \
--repos-file "/opt/scala-steward/repos.md" \
--repo-config "/opt/scala-steward/default.scala-steward.conf" \
--git-author-email ${EMAIL} \
--vcs-api-host "https://api.code.corp.xxx.com/" \
--vcs-login ${LOGIN} \
--git-ask-pass "/opt/scala-steward/.github/askpass/$LOGIN.sh" \
--env-var "SBT_OPTS=-Xmx7168m -Xss1024m -XX:MaxMetaspaceSize=512m" \
--env-var "JAVA_OPTS=-DLOG_LEVEL=DEBUG" \
--do-not-fork \
--disable-sandbox
push
event to any branch. For some reason, one of the pull requests created by a scala-steward-action run did not automatically kick off my github workflows. Has this happened to anyone else? Is this a fluke? Or do I need to listen to pull_request
events as well for scala-steward?
sbt githubWorkflowGenerate