Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Cache `/root/.m2/repository`
See original GitHub issueDescription: I use containers (Ubuntu, Fedora, Almalinux) in GitHub Actions. In my workflows, I am using this action. In the “Post Setup Java” step, I see a warning about a path validation error.
What I have discovered is that the Maven local repository path by default is /root/.m2/repository, so ~/.m2/repository doesn’t exist.
Justification:
This is a very hard issue to discover, and since this path seems to the default on many images, or at least the ones I am using, it should be cached in addition to the usual ~/.m2/repository.
https://github.com/actions/cache/issues/814
Are you willing to submit a PR? Potentially.
Alternatively, allow us as users to configure the cache path ourselves.
Issue Analytics
- State:
- Created a year ago
- Comments:9 (6 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
@tristan957 i am closing the issue because of the problem relates to https://github.com/actions/runner repository and there’s no activity for 2 weeks. Please feel free to create the issue in this project in case of any problem.
Hey everyone,
I will try to provide more context to why is this happening.
When starting a job within a container, the runner will add system volume mounts. The volume mount interesting for this issue is
/github/homewhich will be mapped to thePATH_TO_YOUR_RUNNER_WORK/_temp/_github_home. It is that directory that is going to be used as a HOME, and can ensure that$HOMEdirectory exists regardless of the container you are using.But on the other hand, this introduces problems when users or scripts rely on the predefined $HOME variable that they expect to be set by the container. The issue is especially tricky when you create a docker container action, with the
USERdirective envHOMEenv set.The reason the workaround works, is that the env field overwrites environment in context of this step, so when you invoke a command, it will use envs specified for that step, which is great for this particular use-case.
In situations where you want to customize containers used by jobs, and you are using self-hosted runners, you can use container hooks.
We are aware of this issue, and we are looking at ways to solve it without breaking existing workflows that rely on current behaviour.
I hope this is helpful, and please, let me know if you have any questions regarding this ☺️