2020-10-20 07:27:43
i'm trying to figure out how to do a runtime container for rosesnow as a staged build and to not have `~/.cache` be transferred over as that's fairly big
what are the artefacts it actually needs?
Rotonen
2020-10-20 07:29:10
also having that maven thing fire on the container startup seems like an antipattern for all things "cloud native"
Rotonen
2020-10-20 07:34:40
also one could not fire that up in an airgapped context as the maven startup of jetty hits the network immediately
Rotonen
2020-10-20 07:35:51
oh there's a war
Rotonen
2020-10-20 07:40:25
only copying the .war to the jetty container does not work
can one somehow make a non-selfcontained .war?
Rotonen
2020-10-20 07:42:38
```FROM ubuntu:20.04 as build
ARG DEBIAN_FRONTEND=noninteractive
ARG APT_KEY_DONT_WARN_ON_DANGEROUS_USAGE=true
RUN apt-get update \
&& apt-get install -qq --no-install-suggests --no-install-recommends \
apt-utils \
gpg \
gpg-agent \
ca-certificates \
curl
RUN echo "deb [arch=amd64] http://storage.googleapis.com/bazel-apt stable jdk1.8" \
> /etc/apt/sources.list.d/snowblossom-bazel.list
RUN curl -Ls https://bazel.build/bazel-release.pub.gpg | apt-key add -
RUN apt-get update \
&& apt-get install -qq --no-install-suggests --no-install-recommends \
git \
default-jdk-headless \
maven \
bazel \
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/*
RUN useradd -ms /bin/bash rosesnow
USER rosesnow
WORKDIR /home/rosesnow
RUN git clone --depth=1 --branch=v0.1 \
https://github.com/snowblossomcoin/rosesnow.git
WORKDIR /home/rosesnow/rosesnow
RUN bazel build :RoseSnow_deploy.jar
WORKDIR /home/rosesnow/rosesnow/maven
RUN mvn package
FROM jetty:9-jre11-slim as runtime
COPY --from=build /home/rosesnow/rosesnow/maven/target/snowrosetta-rosesnow.war \
/var/lib/jetty/webapps/ROOT.war
# From repository root:
# docker build -t rosesnow docker/
# docker run -it --rm -p 8080:8080 rosesnow```
i'll make a PR if you make that .war fully self contained
Rotonen
2020-10-20 07:43:15
seems like something you'd have to do in the maven declarations for `mvn package` to do the right thing
Rotonen
2020-10-20 07:44:35
cloud native 101: always use upstream container as base (in this case jetty container)
opsec 101: never leave your build tooling in production servers or containers
Rotonen
2020-10-20 07:50:21
breakdowns of improvements
`ARG` <- only set this environment variable during build time (can also be overridden from command line)
`--no-install-suggests --no-install-recommends` <- smaller transient containers, less waiting at build time
`apt-get clean` <- smaller transient containers
`rm -rf /var/lib/apt/lists/*` <- smaller transient containers
`git clone --depth=1` <- smaller transient containers, less waiting at build time
`RUN useradd` <- don't run builds as root, you pull dynamic stuff in and root has a higher attack surface to the container host
`FROM jetty:9-jre11-slim as runtime` <- use the appropriate upstream container as your runtime container
`COPY --from=build` <- staged build for the most minimal possible runtime
Rotonen
2020-10-20 07:51:20
```org.glassfish.jersey.message.internal.MessageBodyProviderNotFoundException: MessageBodyWriter not found for media type=application/json, type=class io.swagger.oas.inflector.models.ApiError, genericType=class io.swagger.oas.inflector.models.ApiError.```
i guess swagger does not get included in the .war
Rotonen
2020-10-20 07:51:55
you fix, i rebase, i test, and i PR or nag more
Rotonen
2020-10-20 07:52:18
also can has contributor to org? doing the fork repo dance on github, while not tragic, is churn
Rotonen
2020-10-20 08:29:56
actually i'll refactor the dockerfile to copy the current working tree in so it can be used in pipelines, we could look at github actions for that
Rotonen
2020-10-20 08:30:14
also thus gotta jam in appropriate .gitignore and .dockerignore
Rotonen
2020-10-20 11:04:16
i guess that .war being broken is not a super big issue as your container serves a 404 as the root :slightly_smiling_face:
Rotonen
2020-10-20 11:04:31
oh well, i'll put a draft PR together while you figure out how to make a standard .war
Rotonen
2020-10-20 11:16:21
• Add appropriate Docker and git ignore files
• Copy current working tree in instead of git cloning in-container
• This will enable CI/CD down the line off this base
• Reduce transient layer count
• This helps with how demanding the local caching is on the storage of developer machines
• Improve use of apt-get
• Quiet output
• Clean all transient metadata up
• Use an unprivileged user for the build
• General cleanups
• Move to a staged build where the runtime is the standard upstream Jetty 9 container
Known issue: the maven output `.war` does not work. I'll rebase and undraft this PR once a fix for that lands on the `main` branch.
GitHub
2020-10-20 14:25:53
seeing this hurts
you could build a tree object and do actual graph traversals for figuring the api paths out
https://github.com/snowblossomcoin/snowblossom/commit/1cd1f7baaa1f8a5699c59c38aef903f153795355#diff-779b1277371c5e1af96845043eada7cd39e7e24a1c696a0e6f52882f6cfa82a1R49
Rotonen
2020-10-20 14:27:14
i guess these kinds of things are the extra "frameworky bits" you would not like to get in your way
Rotonen
2020-10-20 14:27:48
oh well, getting the crypto stuff right is what matters
Rotonen
2020-10-20 14:28:03
and i'll pitch in container stuff in as getting that stuff right helps with adoption
Rotonen
2020-10-20 14:29:04
i guess i should also do one for the node, the explorer, the pool and for what else?
Rotonen
2020-10-20 15:34:09
Rosetta API (aka coinbase) as some particular requirements for the docker setup: https://www.rosetta-api.org/docs/node_deployment.html ## Multiple Modes
Fireduck
2020-10-20 15:35:08
well, i can also do an ubuntu based runtime in that for the .war
Rotonen
2020-10-20 15:35:46
the one that seems weird to me is they don't want to copy in files from the repo, they want it to pull them from git
Fireduck
2020-10-20 15:36:13
with any luck the jetty image is based on ubuntu, let's check
Rotonen
2020-10-20 15:36:40
well, that's also fair, as they can rebuild that at any point to pull in os updates
Rotonen
2020-10-20 15:37:02
but even a git tag is a floating pointer so someone could do a nasty switcheroo for them
Rotonen
2020-10-20 15:37:49
nope, jetty is debian based
Rotonen
2020-10-20 15:38:10
and they don't offer an ubuntu based image, so i'll roll my own
Rotonen
2020-10-20 15:38:17
but you still need to fix the .war
Rotonen
2020-10-20 15:38:56
installing jetty in ubuntu and putting the .war to the correct place as ROOT.war and starting jetty in the container entrypoint is easy
Rotonen
2020-10-20 15:39:23
I agree I should fix the war, but I'd have to understand what is wrong with it. Ideally I'd remove maven completely from the picture.
Fireduck
2020-10-20 15:39:34
you can use my dockerfile for debugging
Rotonen
2020-10-20 15:40:06
https://github.com/Rotonen/rosesnow/blob/2020-10-20-improve-dockerfile/Dockerfile ```
FROM ubuntu:20.04 as build
ARG DEBIAN_FRONTEND=noninteractive
ARG APT_KEY_DONT_WARN_ON_DANGEROUS_USAGE=true
RUN apt-get update -qq \
&& apt-get install -qq --no-install-recommends --no-install-suggests \
apt-utils \
gpg \
gpg-agent \
ca-certificates \
curl
RUN echo "deb [arch=amd64] http://storage.googleapis.com/bazel-apt stable jdk1.8" \
> /etc/apt/sources.list.d/snowblossom-bazel.list
RUN curl -Ls https://bazel.build/bazel-release.pub.gpg | apt-key add -
RUN apt-get update -qq \
&& apt-get install -qq --no-install-recommends --no-install-suggests \
git \
default-jdk-headless \
bazel \
maven \
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/*
RUN useradd -ms /bin/bash snowblossom
COPY . /home/snowblossom/rosesnow
RUN chown -R snowblossom:snowblossom /home/snowblossom
USER snowblossom
WORKDIR /home/snowblossom/rosesnow
RUN bazel build :RoseSnow_deploy.jar
WORKDIR /home/snowblossom/rosesnow/maven
RUN mvn package
FROM jetty:9-jre11-slim as runtime
COPY --from=build /home/snowblossom/rosesnow/maven/target/snowrosetta-rosesnow.war \
/var/lib/jetty/webapps/ROOT.war
# From repository root:
# docker build -t rosesnow .
# docker run -it --rm -p 8080:8080/tcp rosesnow
```
Rotonen
2020-10-20 15:40:30
and also grab the .gitignore and .dockerignore so you don't put the wrong things into the container per accident
Rotonen
2020-10-20 15:40:44
or just build the war and jam that into a standard jetty container with a volume
Rotonen
2020-10-20 15:40:49
also works
Rotonen
2020-10-20 15:48:14
so, i'll do a second Dockerfile just for rosetta
Rotonen
2020-10-20 15:49:31
one for local dev at repo root, one for shipping to rosetta
Rotonen
2020-10-20 15:57:58
and i'll add the branch it should clone as an argument - git clone --branch limits it to just published objects (branch names, tags), but that should work
Rotonen
2020-10-20 15:59:37
and the second requirement they have is the build staging i already went for anyway
Rotonen
2020-10-20 16:00:23
testing locally and amending PR
still pending a working .war
Rotonen
2020-10-20 16:18:58
so, this works
```FROM ubuntu:20.04 as build
ARG DEBIAN_FRONTEND=noninteractive
ARG APT_KEY_DONT_WARN_ON_DANGEROUS_USAGE=true
RUN apt-get update -qq \
&& apt-get install -qq --no-install-recommends --no-install-suggests \
apt-utils \
gpg \
gpg-agent \
ca-certificates \
curl
RUN echo "deb [arch=amd64] http://storage.googleapis.com/bazel-apt stable jdk1.8" \
> /etc/apt/sources.list.d/snowblossom-bazel.list
RUN curl -Ls https://bazel.build/bazel-release.pub.gpg | apt-key add -
RUN apt-get update -qq \
&& apt-get install -qq --no-install-recommends --no-install-suggests \
git \
default-jdk-headless \
bazel \
maven \
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/*
RUN useradd -ms /bin/bash snowblossom
RUN chown -R snowblossom:snowblossom /home/snowblossom
USER snowblossom
WORKDIR /home/snowblossom
ARG BRANCH=v0.1
RUN git clone --depth=1 --branch=${BRANCH} \
https://github.com/snowblossomcoin/rosesnow.git \
&& rm -rf rosesnow/.git/
WORKDIR /home/snowblossom/rosesnow
RUN bazel build :RoseSnow_deploy.jar
WORKDIR /home/snowblossom/rosesnow/maven
RUN mvn package
FROM ubuntu:20.04 as runtime
ARG DEBIAN_FRONTEND=noninteractive
RUN apt-get update -qq \
&& apt-get install -qq --no-install-recommends --no-install-suggests \
jetty9
RUN rm -rf /var/lib/jetty9/webapps/root/
COPY --from=build /home/snowblossom/rosesnow/maven/target/snowrosetta-rosesnow.war \
/var/lib/jetty9/webapps/ROOT.war
RUN chown -R jetty:adm /var/lib/jetty9/
USER jetty
ENV JETTY_HOME=/usr/share/jetty9/
ENV JETTY_STATE=/var/lib/jetty9/jetty.state
ENV JAVA_OPTS=-Djava.awt.headless=true
CMD /usr/share/jetty9/bin/jetty.sh run
# For local dev vs. main (or any other branch or tag):
# docker build --build-arg BRANCH=main -t rosesnow-rosetta .
# docker run -it --rm -p 8080:8080/tcp rosesnow-rosetta```
Rotonen
2020-10-20 16:19:37
in the early boot log there's some nonsense about how the jetty in debian is deeply systemd integrated and how it cannot find the state file from the process manager, but that's safe to ignore
Rotonen
2020-10-20 16:20:28
so, if you have a branch where you try to fix the .war, you can use that to check your working
Rotonen
2020-10-20 16:21:05
and i think the branch heads are also published objects on the public github so you could be able to just pass in a hash as a build arg
Rotonen
2020-10-20 16:22:09
github optimises some lesser used facets of their git remotes for obvious reasons of scale and performance, and they're not fully open about the things they've not taken a stance on yet - so this stuff sometimes flutters back and forth without any announcements from them (which is fair, they never promised it'd work and no normal tooling does that)
Rotonen
2020-10-20 16:22:57
as far as i can tell that now fulfills all of the rosetta specs
1) build from git
2) separate build time and run time
3) all based on ubuntu
Rotonen
2020-10-20 16:23:24
if i missed any, give me a poke
Rotonen
2020-10-20 16:40:19
oh, missed a couple of the environment variables from the systemd file
Rotonen
2020-10-20 16:44:41
@Fireduck edited the dockerfile above, there you go, for your local experimentation
Rotonen
2020-10-20 16:46:17
Thanks I'll take a look. But honestly, it might be a few days before I am up to fighting jetty and war files more
Fireduck
2020-10-20 16:47:25
I find it really frustrating. The introspection of the framework I am using is weird.
Fireduck
2020-10-20 16:47:51
And I have plenty of work to do implementing the actual api calls
Fireduck
2020-10-20 16:48:02
that's fair, but what i can offer is helping you out with any container stuff - i'm not in a particular hurry
Rotonen
2020-10-20 16:48:17
you need to find a second java dude
Rotonen
2020-10-20 16:48:31
i can do plenty of systems and packaging and CI/CD stuff for snowblossom
Rotonen
2020-10-20 16:48:33
Ideally I'll figure out how to make the war file correctly and just do it from bazel
Fireduck
2020-10-20 16:48:52
that works as well, changing those dockerfiles to match that flow is a non-issue
Rotonen
2020-10-20 16:49:03
whenever you think you got it, ping me and i'll reshape and rebase
Rotonen
2020-10-20 16:49:13
Awesome, thanks
Fireduck
2020-10-20 16:49:37
should i also try to do one for the node?
Rotonen
2020-10-20 16:49:59
lowering the barrier of entry for nodes could be healthy
Rotonen
2020-10-20 16:50:31
We have one for the node that could use some fixing
Fireduck
2020-10-20 16:51:00
and the more i look at that rosetta build spec, the more i think they just don't trust people on average to have a sane .dockerignore in their repositories to filter out any potential build outputs, so they want a hard guarantee of reproducible builds
which is fair, given what they do
Rotonen
2020-10-20 16:51:13
leading up to the question: do i do the same for the node?
Rotonen
2020-10-20 16:51:14
Plus should I make a dockerhub account and publish things there?
Fireduck
2020-10-20 16:51:37
yes, but then you should give me some org access to snowblossom on github, so i can automate that with github actions
Rotonen
2020-10-20 16:51:52
Yeah, will do
Fireduck
2020-10-20 16:52:00
github orgs also have a secrets management scheme these days so you can put the dockerhub upload key there for the pipeline to use
Rotonen
2020-10-20 16:52:57
and i'd also add branch protection rules on the main / master branches of all the repositories so no one can ever force push to master
Rotonen
2020-10-20 16:53:33
and one can add more branch protection rules if you get more developers, like mandating all changes to master come through PRs (and that the tests pass on said PRs)
Rotonen
2020-10-20 16:53:43
for now i'd just go for "tests run on all commits"
Rotonen
2020-10-20 16:54:07
then after that "creating a tag builds a container and pushes to dockerhub"
Rotonen
2020-10-20 16:54:48
never did anything with github actions so far, so i'm very curious about all that
Rotonen
2020-10-20 16:55:03
especially their design paradigm on container promotion pipelines is something i'd like to give a spin
Rotonen
2020-10-20 16:55:42
At my work they were in some way unhappy with it and switched to gitlab for the automation
Fireduck
2020-10-20 16:56:16
Code and pr work still in github, just automatic mirrored to gitlab for ci
Fireduck
2020-10-20 16:57:35
i try to be able to use ~anything, so i'm currently on a mix of jenkins x, jenkins, spinnaker, teamcity, bamboo, screwdriver, circle, travis (and probably forgot two thirds of what i've used in the past decade - i started with tinderbox)
Rotonen
2020-10-20 16:57:57
task durability engines are not magic, they all do about the same thing
Rotonen
2020-10-20 16:58:17
serialization, marshalling, execution, passing things around, distributed map reduce, storage of artefacts
Rotonen
2020-10-20 16:58:32
Yep
Fireduck
2020-10-20 16:59:11
and very good fun everything always boils down to "returns zero, or not"
Rotonen
2020-10-20 17:26:45
this looks good for jamming into a github action
https://github.com/bazelbuild/bazelisk A user-friendly launcher for Bazel.
Rotonen
2020-10-20 17:29:28
not sure if that or docker is the neater way to go here, oh well, i'll worry about that later and i'll do the docker image for the node first
Rotonen
2020-10-20 17:36:29
that might be handy, especially if bazel continues to make breaking changes
Fireduck
2020-10-20 17:36:44
for example, right now if you wanted to go back and build old versions of snowblossom, it wouldn't work
Fireduck
2020-10-20 17:36:57
because bazel has changed things. But if we could specify which version, then sure.
Fireduck
2020-10-20 17:39:25
i think i'll give that a spin already for the node dockerfile
Rotonen
2020-10-20 17:44:32
@Clueless does the `COPY --chown=docker:docker` already work reliably on all platforms?
Rotonen
2020-10-20 17:45:01
i guess that's not really an issue across containers like that
Rotonen
2020-10-20 17:45:46
oh that wasn't from you, but from some community member
Rotonen
2020-10-20 17:46:44
or was that the other dev who was on board early on?
Rotonen
2020-10-20 17:46:56
that file is pretty well done
Rotonen
2020-10-20 17:47:36
i'm not exactly sure of the multi use paradigm in there
do we know if we have any downstream users? if i break that up into multiple files, that'd break their flow
Rotonen
2020-10-20 17:50:15
@Rotonen I made some distance with a new dockerfile but got hung up on something. I have it somewhere if you want reference.
Clueless
2020-10-20 17:50:58
push it onto a branch and i'll cherry-pick
Rotonen
2020-10-20 17:52:22
in general i always like having more perspectives and approaches around
Rotonen
2020-10-20 17:53:05
*https://github.com/snowblossomcoin/rosesnow/compare/b3c6c0be4f23...40955c7596f3*
https://github.com/snowblossomcoin/rosesnow/commit/40955c7596f3e11f7d8cdda9a9e3cf0e968eee01 - Working on block data access
GitHub
2020-10-20 17:55:22
@Clueless did you make a snowblossom dockerhub repo? If so, can I have access to it?
Fireduck
2020-10-20 17:56:46
and put the upload token into the secrets storage on the repo
https://docs.github.com/en/free-pro-team@latest/actions/reference/encrypted-secrets
Rotonen
2020-10-20 17:57:13
@Fireduck how do you run the tests?
Rotonen
2020-10-20 17:58:15
bazel test ...
Fireduck
2020-10-20 18:00:17
does it make a difference if one uses the deploy target?
`bazel test :SnowBlossomNode_deploy.jar`
would that actually compile the node as well in an usable way?
Rotonen
2020-10-20 18:00:47
I have no idea what that command would do
Fireduck
2020-10-20 18:01:03
I actually run this: bazel build :all :IceLeaf_deploy.jar :IceLeafTestnet_deploy.jar && bazel test ...
Fireduck
2020-10-20 18:01:18
And I have some other automation that picks up those deploy files and moves them to my desktop for testing
Fireduck
2020-10-20 18:02:21
that command seems to have built the node deployment and nothing else
Rotonen
2020-10-20 18:03:01
and a naked `bazel test` does nothing - i'm missing something very obvious here as i have no idea of the tooling or codebase
Rotonen
2020-10-20 18:03:18
so normal build will make the bazel scripts, like bazel-bin/SnowBlossomClient and such
Fireduck
2020-10-20 18:03:35
if you want the stand alone deploy.jar files you have to ask for them explicitly
Fireduck
2020-10-20 18:03:47
bazel test :all used to use
Fireduck
2020-10-20 18:03:50
and that seems to override whatever test does, which is weird, but ok
Rotonen
2020-10-20 18:04:03
but then something changed so "bazel test ..." works
Fireduck
2020-10-20 18:04:11
with literally three dots
Fireduck
2020-10-20 18:04:15
i'm thinking of splitting the tests up per output
Rotonen
2020-10-20 18:04:29
literally three dots was not what i expected that to mean :smile:
Rotonen
2020-10-20 18:04:49
ha, yeah
Fireduck
2020-10-20 18:05:00
`bazel test ...` runs something even without building anything
Rotonen
2020-10-20 18:05:10
is 108 tests expected?
Rotonen
2020-10-20 18:05:20
@Fireduck @Rotonen I have a framework for building individual pieces and entry points for each one. I'm even able to integrate with x window system in linux and provide a GUI. Am creating that branch right now.
Clueless
2020-10-20 18:06:24
I don't think 108 tests exist, but I'm not sure. There should be 5 or 6 sub tasks, which are tests in separate components
Fireduck
2020-10-20 18:06:30
which probably around a dozen in each one
Fireduck
2020-10-20 18:06:33
so it isn't way off base
Fireduck
2020-10-20 18:06:41
i guess it builds 108 files to run the 6
Rotonen
2020-10-20 18:06:45
@Rotonen I think it's here: https://github.com/snowblossomcoin/snowblossom-docker
Clueless
2020-10-20 18:07:31
yup, that's current with what I had in my build directory on my docker server.
Clueless
2020-10-20 18:07:58
bah, i wanted to tree shake the stability of the tests and run them n+1 times in a row and see if they can be flaky
bazel is clever and has cached the results for me and skips the build and the tests, "..."
Rotonen
2020-10-20 18:08:41
that one is about as properly done as one can do a dockerfile
Rotonen
2020-10-20 18:09:22
a bit of inline cleanups here and there would help, but practically does not matter for something like this
Rotonen
2020-10-20 18:09:24
@Fireduck I sent an ownership invite to your email address for dockerhub's snowblossom org
Clueless
2020-10-20 18:10:10
and `DEBIAN_FRONTEND=noninteractive` to get rid of the `-y`
Rotonen
2020-10-20 18:10:16
last I was doing was screwing with dockerhub automatic building from github repos.
Clueless
2020-10-20 18:10:45
there's now a github action for that
Rotonen
2020-10-20 18:10:52
@Clueless thanks
Fireduck
2020-10-20 18:12:06
both work, though
Rotonen
2020-10-20 18:15:08
i guess one could start tagging the dockerfile repository and building the images off tags via actions and uploading those to dockerhub
seems all the groundwork is actually done there
Rotonen
2020-10-20 18:15:25
just use the tag name as the environment variable for the version and you're good to go
Rotonen
2020-10-20 18:16:06
actually one could even go a step further and trigger an action on the snowblossom repository when that gets a tag to tag the current master of the docker repo to fully automate that
Rotonen
2020-10-20 18:16:29
starting with manual double tagging and seeing how it goes is probably prudent
Rotonen
2020-10-20 18:17:12
@Rotonen want to be in charge of the dockerhub org and the dockerfiles?
Fireduck
2020-10-20 18:17:19
and i guess the container could run the tests at build time so it halts the deployment if someone tagged bad code
Rotonen
2020-10-20 18:17:31
also, is there a good way to run two things in a docker image? Like if we want a node and the explorer as one docker unit.
Fireduck
2020-10-20 18:17:44
not in particular, but i'm not against that either, and @Clueless seems to be on top of things too
Rotonen
2020-10-20 18:18:12
@Fireduck you can jam any process manager in, but why? just use a proper orchestration model
Rotonen
2020-10-20 18:21:07
orchestration model meaning something like terraform?
Fireduck
2020-10-20 18:21:54
more like rancher 1.6 or amazon fargate
Rotonen
2020-10-20 18:22:15
or any kubernetes cluster for that matter :slightly_smiling_face:
Rotonen
2020-10-20 18:22:26
so rancher 2, GKE, AKE, EKS, etc.
Rotonen
2020-10-20 18:22:46
but locally on your computer, docker-compose should do the trick
Rotonen
2020-10-20 18:23:16
and you can make just one image and change the entry points in the compose file
but rather do lean images, one per purpose
Rotonen
2020-10-20 18:24:17
@Rotonen My implementation allows you to build specific parts, or all in one and use an entrypoint, I think.
Clueless
2020-10-20 18:24:33
haven't touched it in 8 months though. I should.
Clueless
2020-10-20 18:24:44
yep, it looked to cover all cases
Rotonen
2020-10-20 18:25:23
that should serve as-is for dockerhub uploads via github actions
Rotonen
2020-10-20 18:25:54
i think the only broken thing is the now-too-old version pinning of bazel
Rotonen
2020-10-20 18:26:05
but as that's configurable through the environment, that's fine too
Rotonen
2020-10-20 18:26:17
win!
Clueless
2020-10-20 18:29:49
so i'll clean up my rosetta dockerfile sometime this week and we can also look at the github actions -> dockerhub stuff
Rotonen
2020-10-20 18:30:08
i'll collapse the rosetta back into one and just only provide that one in-repo as it originally was
Rotonen
2020-10-20 18:31:26
awesome
Fireduck
2020-10-20 21:18:24
i still had time to finish this tonight after all
https://github.com/snowblossomcoin/rosesnow/pull/1
test locally and feedback is welcome on the PR • Reduce transient layer count
• This helps with how demanding the local caching is on the storage of developer machines
• Improve use of apt-get
• Quiet output
• Clean all transient metadata up
• Use an unprivileged user for the build
• General cleanups
• Move to a staged build and use Jetty 9 from the Ubuntu repositories
Known issue: the maven output `.war` does not work. I'll rebase and undraft this PR once a fix for that lands on the `main` branch.
Rotonen